On Friday 05 May 2006 05:28, Михаил Монашёв wrote:
> Здравствуйте nginx-ru,
>
> Пробую сейчас реализовать кэширование страничек через внутренний
> редирект в nginx, но возникла некоторая проблема с алгоритмом
> создания пути и имени файла, в который будет записываться кэш. Так
> например в какие файлы на диске можно преобразовать вот эти два
> url-я:
>
> и
>
>
> На диске не может же быть директории и файла с одним именем! И
> теоретически содержимое этих двух ссылок может быть разным. А хочется
> обрабатывать общий случай.
Делай md5 сумму урлы. Примерно так mod_disk_cache Apache делает.
>
> Из этой проблемы вытекает другая. При последующих обращениях к
> мы в кэше уже имеем
> директорию cache/tags/local/network/connection/ , а не файл, который
> можно было бы отдать.
Вообще-то, если со слешем на конце и без это разное, но по-моему, это криво и
чревато.
>
> Т.е. проблема в следующем: как корректно преобразовывать url в его
> отображение на диске? При этом хотелось бы сохранить иерархию
> директорий, если это возможно.
Если нужна не сама иерархия, а просто упоминание об урле в имени файла по
которому потом можно найти этот файл в кеше, то можно просто убирать из урлы
все спецсимволы и добавлять полученное к md5 сумме. Напр. из
получится:
6b65d48cd6a108a90c9cdc14c518bdbe-example-com-dir-file-html
Далее можно уже для оптимизации disk io создавать дерево, напр.
./6/b/65d48cd6a108a90c9cdc14c518bdbe-example-com-dir-file-html
Подобное у меня было реализовано для Catalyst & lighttpd. Причем на стороне
lighttpd сперва искался файл в кеше используя встроенный Lua модуль, т.е. до
перла не доходило.
На сервере с 50-70 динамических запросов в сек итог следующий:
При 100-300к файлов в кеше загрузка падает.
При 2-4 миллиона файлов в кеше нагрузка возрастает значительно и сервер жутко
тормозит из-за полной загрузки диска судя по gstat.
Причем создание дерева в кеше практически не влияло ни на что. Что 1к файлов в
директории, что 1млн. - все одно и тоже.
Полностью аналогичные результаты были и на Apache + mod_disk_cache.
В итоге кеш этот был отключен и сейчас работает все полностью динамически.
Нагрузка не более 0.5 в часы пик.
Сделал вывод что изначально проблемы были в большом кол-ве процессов fastcgi
при малом кол-ве памяти (512М) и использовании сокетов для fastcgi вместо
tcp. Теперь 4 fastcgi процесса делают все дело не особо напрягаясь.
