etags и ферма серверов

Я узнал из широко известных скринкастов scaling rails, что в какой-то момент, когда ваш сайт становится все больше и больше, кэширование прокси-это путь. Прокси-кэширование использует etag, среди прочего, и поскольку ETag может быть более специфичным и сильным валидатором, возможно, это путь. Однако я также слышал, что в сценариях фермы серверов etag не является правильным решением, потому что он может варьироваться между серверами (как?)

Это кажется противоречивым, то есть, скорее всего, один реализует e-tag на основе кэширование прокси-серверов, если они работают на больших фермах серверов с балансировкой нагрузки. Итак, если e-tag терпит неудачу в этой ситуации, как они это делают? : last_modified-не самый лучший вариант.

В приложении rails скажем, если мои etags в действии post index 

:etag => "all_posts_#{Post.count}".

Будет ли это отличаться от сервера к серверу, если это ферма серверов с балансировкой нагрузки?

1 2
ruby-on-rails performance caching scalability

1 ответ:

Обычно, когда они говорят об Etags, варьирующихся между серверами, это относится к статическому соединению, обслуживаемому Apache. По умолчанию Apache включает индекс файла в Etag . Если файлы не находятся на общем ресурсе (например, экспортированном NFS NAS), то индекс файла будет отличаться на каждом сервере. Как правило, рекомендуется настроить Apache следующим образом: 

FileETag MTime Size

Но даже это имеет возможность различий, если время модификации изменяется по всей сервера.

Однако для нестатического контента вы генерируете Etag в своем коде, поэтому он будет одинаковым на нескольких серверах.

3