Всем привет!
Меня тоже интересует идея общего кеша для нескольких nginx. При этом
понравилась идея про оценку эффективности существующего кеша. Что бы точно
понимать есть ли смысл в идеи общего кеша. А потому хотелось бы узнать,
кто-то пробовал считать/оценивать эффективность кеша nginx? каким образом
это можно сделать? Мне кроме тестирования с помощью ab ни чего в голову и
не приходит, а хотелось бы какой-то более серьезный расчет получить

13 апреля 2015 г., 13:31 пользователь Bogdan <bogdar@gmail.com> написал:

> Привет.
>
> 1. Общий кэш на файловой системе - единая точка отказа. В лучшем случае
> потеряете сам кэш - в худшем - все балансировщики.
> 2. Эффективность существующего кэша надо оценивать, если там 90% - я не
> силён в математике, но буст будет не так велик ИМХО.
> 3. Если хочется новых острых впечатлений в продакшене - можно кэшировать в
> общем мемкэше. Но есть шанс потерять кэш вообще, либо получить холодный кэш.
> 4. Можно отдавать ответы не с бэкендов, а через кластер couchbase -
> http://labs.couchbase.com/couchbase-nginx-module/, но придётся доработать
> приложение так, чтобы оно сам писало кэш в кучбейс и самостоятельно же
> чистило его.
>
>
> 2015-03-23 17:58 GMT+03:00 Илья Шипицин <chipitsine@gmail.com>:
>
>> расчеты можно сделать исходя, например, из access-логов.
>> залогируйте $upstream_response_time, посмотрите, какие запросы могли
>> бы обработаться из кеша, если бы он был общий, просуммируйте.
>>
>> можно взять граничное условие, что, если запрос берется из кеша, то
>> временнЫе затраты на это равны нулю, т.е. в первом приближении
>> пренебречь дисковым вводом-выводом. это может быть справедливо, если у
>> вас действительно тяжелая генерация ответов.
>>
>> 23 марта 2015 г., 18:24 пользователь Михаил Пульман <pullmix@gmail.com>
>> написал:
>> > Расчетов нет, есть предположение. Вы подскажите как реализовать, а
>> > последующие тесты покажут результативность такого решения. Чисто из
>> > логических соображений прирост должен быть обязательно.
>> >
>> > С уважением, Михаил
>> >
>> > 23 марта 2015 г., 16:10 пользователь Илья Шипицин <chipitsine@gmail.com
>> >
>> > написал:
>> >
>> >> а есть расчеты, подтверждающие хороший прирост производительности ?
>> >>
>> >> 23 марта 2015 г., 17:30 пользователь Михаил Пульман <pullmix@gmail.com
>> >
>> >> написал:
>> >> > Ситуация в том что есть железный балансировщик, он раскидывает
>> трафик по
>> >> > 4-6
>> >> > штукам nginx, а нжинксы балансируя траффик с помощью апстрима
>> >> > перенаправляют
>> >> > на бэкенд сервера. На балансировщиках nginx настроен кэш. Получается
>> >> > что на
>> >> > всех балансировщиках разный кеш. Допусти клиентский запрос попавший
>> на
>> >> > балансир номер 1 кеша там не обнаружилось и запрос пошел на бэкенд,
>> в то
>> >> > время как на балансировщике номер 2 нужный кеш в этот момент был, но
>> по
>> >> > понятным причинам не был использоан. Вообщем если сделать общий кеш
>> для
>> >> > всех
>> >> > балансировщиков nginx можно получить хороший прирост
>> >> > производительности.
>> >> >
>> >> > С уважением, Михаил
>> >> >
>> >> > 23 марта 2015 г., 12:56 пользователь Илья Шипицин <
>> chipitsine@gmail.com>
>> >> > написал:
>> >> >
>> >> >> возможно, вы придете к монстроидной схеме
>> >> >>
>> >> >> nginx --> squid (с поддержкой ICAP) --> бекенды
>> >> >>
>> >> >> и даже после танцев с бубном вы ее настроите.
>> >> >>
>> >> >> но, практика показывает, что в таких случаях надо уметь отвечать на
>> >> >> вопрос "зачем это надо ?".
>> >> >> после ответа на который часто оказывается, что на самом деле - не
>> надо.
>> >> >>
>> >> >> вы бы рассказали про вашу ситуацию в деталях ?
>> >> >>
>> >> >> 23 марта 2015 г., 13:54 пользователь Михаил Пульман <
>> pullmix@gmail.com>
>> >> >> написал:
>> >> >> > Добрый день коллеги!
>> >> >> >
>> >> >> > На фронте имеется n-ое количество nginx которые выступают в
>> качестве
>> >> >> > балансировщиков.
>> >> >> > Нужно наладить единый кэш для всех фронтенд nginxов. Какие есть
>> >> >> > возможности
>> >> >> > в nginx для реализации этой задачи?
>> >> >> >
>> >> >> > С уважением, Михаил
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > nginx-ru mailing list
>> >> >> > nginx-ru@nginx.org
>> >> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> >> _______________________________________________
>> >> >> nginx-ru mailing list
>> >> >> nginx-ru@nginx.org
>> >> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > nginx-ru mailing list
>> >> > nginx-ru@nginx.org
>> >> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >> _______________________________________________
>> >> nginx-ru mailing list
>> >> nginx-ru@nginx.org
>> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> >
>> >
>> >
>> > _______________________________________________
>> > nginx-ru mailing list
>> > nginx-ru@nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> WBR, Bogdan B. Rudas
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru