Configurando um proxy reverso para armazenar imagens em cache

Question

Eu escrevi um servidor Python rápido para exibir imagens reamostradas. Por exemplo, um URL pode ser parecido com http://images.domain.com/resample/100x100/9f362e1994264321.jpg . Sendo que as imagens de reamostragem são caras, uma camada de cache é necessária. Parece que um proxy reverso nginx seria uma boa opção para isso, e aqui e aqui parecem bons lugares para começar.

No entanto, existe um problema. Existem milhões de imagens, portanto, armazenando http://images.domain.com/resample/100x100/9f362e1994264321.jpg no sistema de arquivos como /home/nginx/cache/resample/100x100/9f362e1994264321.jpg (ou algo do tipo), eventualmente cache/resample/100x100/ terá milhões de arquivos, o que tornará as pesquisas de arquivos muito ineficientes.

Eu lido com este problema enquanto armazeno as imagens originais distribuindo-as entre muitos subdiretórios, por exemplo, 9f/36/9f362e1994264321.jpg . No entanto, não tenho certeza de como eu poderia fazer o mesmo com o nginx. Eu poderia mudar a URL para fazer o mesmo, e eu vou, se essa for a única solução, mas prefiro manter a URL o mais bonita possível.

Posso fazer isso com o nginx? Se não com nginx, posso fazer outra coisa, como verniz?

    

Answer 1

Em vez de usar alguns links irrelevantes no Google, você definitivamente deveria ter lido a documentação sobre ngx_http_proxy_module.html .

A diretiva proxy_cache é exatamente o que você precisa. A configuração deve ser algo como isso.

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
        }

        # ...

    }

}

Na pasta /var/www/cache , será criada a estrutura de diretórios de dois níveis. A resposta em cache para o link será salva como md5 de proxy_cache_key value. Por exemplo, se você descomentar #proxy_cache_key $scheme$proxy_host$request_uri; acima, a resposta será armazenada em cache no arquivo / var / www / cache / f / 08 / 8db24849a311cc3314955992686d308f

porque %código% e level = 1: 2 traduzido para a estrutura dir, contando os últimos caracteres, ... 08f - > f / 08 / md5value

    

Answer 2

which will make file lookups very inefficient.

Isso parece otimização prematura.

Você não forneceu informações sobre qual sistema operacional está sendo executado. Já que você mencionou o Varnish, eu assumo que isso é um pouco do Unix. Assumindo que seja Linux (embora a maior parte disso se aplique a outros SO também) ...

Você realmente mediu e comparou isso com a abordagem de reescrever caminhos? Se você está sofrendo uma degradação, provavelmente está fugindo de um sistema de arquivos muito antigo (ou de um que tenha sido atualizado por um patch parcial). Com ext4 ou BTRFS, não esperaria ver uma diferença mensurável.

Mas isso é um pouco além do ponto. Proxies reversos sabem que podem estar armazenando muitos arquivos em cache - e não necessariamente mapearão caminhos de URL diretamente para os caminhos do sistema de arquivos.

Você terá problemas com um número muito grande de arquivos gerenciados pelo cache - mas isso tem a ver com a metodologia VFS /. Diminuir o vfs_cache_pressure deve ajudar.