Всем привет! Меня тоже интересует идея общего кеша для нескольких nginx. При этом понравилась идея про оценку эффективности существующего кеша. Что бы точно понимать есть ли смысл в идеи общего кеша. А потому хотелось бы узнать, кто-то пробовал считать/оценивать эффективность кеша nginx? каким образом это можно сделать? Мне кроме тестирования с помощью ab ни чего в голову и не приходит, а хотелось бы какой-то более серьезный расчет получить
13 апреля 2015 г., 13:31 пользователь Bogdan <bog...@gmail.com> написал: > Привет. > > 1. Общий кэш на файловой системе - единая точка отказа. В лучшем случае > потеряете сам кэш - в худшем - все балансировщики. > 2. Эффективность существующего кэша надо оценивать, если там 90% - я не > силён в математике, но буст будет не так велик ИМХО. > 3. Если хочется новых острых впечатлений в продакшене - можно кэшировать в > общем мемкэше. Но есть шанс потерять кэш вообще, либо получить холодный кэш. > 4. Можно отдавать ответы не с бэкендов, а через кластер couchbase - > http://labs.couchbase.com/couchbase-nginx-module/, но придётся доработать > приложение так, чтобы оно сам писало кэш в кучбейс и самостоятельно же > чистило его. > > > 2015-03-23 17:58 GMT+03:00 Илья Шипицин <chipits...@gmail.com>: > >> расчеты можно сделать исходя, например, из access-логов. >> залогируйте $upstream_response_time, посмотрите, какие запросы могли >> бы обработаться из кеша, если бы он был общий, просуммируйте. >> >> можно взять граничное условие, что, если запрос берется из кеша, то >> временнЫе затраты на это равны нулю, т.е. в первом приближении >> пренебречь дисковым вводом-выводом. это может быть справедливо, если у >> вас действительно тяжелая генерация ответов. >> >> 23 марта 2015 г., 18:24 пользователь Михаил Пульман <pull...@gmail.com> >> написал: >> > Расчетов нет, есть предположение. Вы подскажите как реализовать, а >> > последующие тесты покажут результативность такого решения. Чисто из >> > логических соображений прирост должен быть обязательно. >> > >> > С уважением, Михаил >> > >> > 23 марта 2015 г., 16:10 пользователь Илья Шипицин <chipits...@gmail.com >> > >> > написал: >> > >> >> а есть расчеты, подтверждающие хороший прирост производительности ? >> >> >> >> 23 марта 2015 г., 17:30 пользователь Михаил Пульман <pull...@gmail.com >> > >> >> написал: >> >> > Ситуация в том что есть железный балансировщик, он раскидывает >> трафик по >> >> > 4-6 >> >> > штукам nginx, а нжинксы балансируя траффик с помощью апстрима >> >> > перенаправляют >> >> > на бэкенд сервера. На балансировщиках nginx настроен кэш. Получается >> >> > что на >> >> > всех балансировщиках разный кеш. Допусти клиентский запрос попавший >> на >> >> > балансир номер 1 кеша там не обнаружилось и запрос пошел на бэкенд, >> в то >> >> > время как на балансировщике номер 2 нужный кеш в этот момент был, но >> по >> >> > понятным причинам не был использоан. Вообщем если сделать общий кеш >> для >> >> > всех >> >> > балансировщиков nginx можно получить хороший прирост >> >> > производительности. >> >> > >> >> > С уважением, Михаил >> >> > >> >> > 23 марта 2015 г., 12:56 пользователь Илья Шипицин < >> chipits...@gmail.com> >> >> > написал: >> >> > >> >> >> возможно, вы придете к монстроидной схеме >> >> >> >> >> >> nginx --> squid (с поддержкой ICAP) --> бекенды >> >> >> >> >> >> и даже после танцев с бубном вы ее настроите. >> >> >> >> >> >> но, практика показывает, что в таких случаях надо уметь отвечать на >> >> >> вопрос "зачем это надо ?". >> >> >> после ответа на который часто оказывается, что на самом деле - не >> надо. >> >> >> >> >> >> вы бы рассказали про вашу ситуацию в деталях ? >> >> >> >> >> >> 23 марта 2015 г., 13:54 пользователь Михаил Пульман < >> pull...@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