Я написал быстрый Python-сервер для обслуживания пересэмплированных изображений. Например, URL-адрес может выглядеть примерно так http://images.domain.com/resample/100x100/9f362e1994264321.jpg. Поскольку передискретизация изображений стоит дорого, необходим слой кеширования. Похоже, что обратный прокси nginx был бы хорошим вариантом для этого, и Вот и Вот кажется хорошим местом для начала.
Однако есть проблема. Есть миллионы изображений, поэтому, сохраняя http://images.domain.com/resample/100x100/9f362e1994264321.jpg в файловой системе как /home/nginx/cache/resample/100x100/9f362e1994264321.jpg (или что-то в этом роде), в конце концов cache/resample/100x100/ будет содержать миллионы файлов, что сделает поиск файлов очень неэффективным.
Я решаю эту проблему, сохраняя исходные изображения, распределяя их по множеству подкаталогов, например, 9f/36/9f362e1994264321.jpg. Однако я не уверен, как я могу сделать то же самое с nginx. Я мог бы изменить URL-адрес, чтобы сделать то же самое, и я сделаю это, если это единственное решение, но я бы предпочел, чтобы URL-адрес был как можно более красивым.
Могу ли я сделать это с помощью nginx? Если не с nginx, можно еще что-нибудь, например лак?
Вместо этого погуглите несколько нерелевантных ссылок, вам определенно стоит прочитать документацию ngx_http_proxy_module.html.
Директива proxy_cache именно то, что вам нужно. Конфигурация должна выглядеть примерно так.
http {
# ...
proxy_cache_path /var/www/cache levels=1:2 keys_zone=imgcache:10m max_size=1000m inactive=720m;
proxy_temp_path /var/www/cache/tmp;
# ...
server {
# ...
location /resample {
proxy_pass http://bla.bla.my.backend;
proxy_cache imgcache;
#proxy_cache_key $scheme$proxy_host$request_uri;
#proxy_cache_valid 200 302 60m;
#proxy_cache_valid 404 10m
}
# ...
}
}
в /var/www/cache В папке будет создана структура каталогов двух уровней. И кешированный ответ для http://mysite.com/resample/dir/file.jpg будет сохранен как md5 из proxy_cache_key стоимость. Например, если вы раскомментируете #proxy_cache_key $scheme$proxy_host$request_uri; выше, ответ будет кэширован в файл / var / www / cache / f / 08 / 8db24849a311cc3314955992686d308f
Так как MD5 ("http://bla.bla.my.backend/resample/dir/file.jpg") = 8db24849a311cc3314955992686d308f и level = 1: 2 переведен в структуру dir, считая символы с последнего, ... 08f -> f / 08 / md5value
что сделает поиск файлов очень неэффективным.
Это звучит как преждевременная оптимизация.
Вы не предоставили никакой информации о том, на какой ОС он работает. Поскольку вы упомянули Varnish, я предполагаю, что это некоторая разновидность Unix. Предполагая, что это Linux (хотя большая часть этого относится и к другим ОС) ....
Вы действительно измерили это и сравнили с подходом переписывания путей? Если вы наблюдаете ухудшение, вероятно, вы используете очень старую файловую систему (или ту, которая была обновлена путем частичного исправления). С ext4 или BTRFS я не ожидал увидеть ощутимой разницы.
Но это совсем не главное. Обратные прокси-серверы знают, что они могут кэшировать множество файлов - и не обязательно будут сопоставлять пути URL-адресов напрямую с путями файловой системы.
Вы столкнетесь с проблемами с очень большим количеством файлов, управляемых кешем, но они связаны с методологией VFS /. Уменьшение vfs_cache_pressure должно помочь.
