Комментарии 32
Еще есть server side includes
Сразу, что бросилось в глаза:
gzip_comp_level 9;
Зачем? 4-5 Хватит за глаза. Этим вы нагружаете процессор не нужной работой по сжатию. Эффект при сжатии с коэффициентом выше 5 — минимальный и не стоит того.
gzip_comp_level 9;
Зачем? 4-5 Хватит за глаза. Этим вы нагружаете процессор не нужной работой по сжатию. Эффект при сжатии с коэффициентом выше 5 — минимальный и не стоит того.
Что-то по-моему перемудрили. Чем родной кеш IIS'а не угодил? nginx это замечательно, но зачем еще один балансировщик? Чем больше звеньев, тем неустойчивей система, на мой взгляд. Первый балансировщик — железка или тоже nginx?
Я так понял первая железка — это простой сервер с *unx на борту, на котором и идет это кешировани.
Но зачем на столько все сложно делать, я не пойму…
Но зачем на столько все сложно делать, я не пойму…
Первый балансировщик — HAproxy, собираемся добавить второй и собрать кластер.
Кеш IIS не угодил тем, что сервера приложений и так загружены, и надо было вывести сжатие страниц с них.
Кеш IIS не угодил тем, что сервера приложений и так загружены, и надо было вывести сжатие страниц с них.
nginx прекрасен, спору нет)
Только что-то тут кажется лишним:
1. либо nginx+IIS, на nginx балансировать и кешировать,
2. либо HAproxy+IIS, на IIS кешировать, при правильном использовании и нагрузка на сервер упадет соответственно сразу.
Только что-то тут кажется лишним:
1. либо nginx+IIS, на nginx балансировать и кешировать,
2. либо HAproxy+IIS, на IIS кешировать, при правильном использовании и нагрузка на сервер упадет соответственно сразу.
А, ну и третий вариант: nginx+IIS, балансирование nginx, кеш на IIS )
Чем плох вариант nginx — haproxy — backend?
При этом nginx раздает статику, держит коннекты, буферизирует, хапрокси обеспечивает равномерную нагрузку на бекенды и отказоустойчивость, одновременно защищает от превышения кол-ва коннектов не бекенд.
При этом nginx раздает статику, держит коннекты, буферизирует, хапрокси обеспечивает равномерную нагрузку на бекенды и отказоустойчивость, одновременно защищает от превышения кол-ва коннектов не бекенд.
curl -A "WGET-POST-daemon" http://www.wildberries.ru >> /dev/null
:P
Хм, я бы обновлял нужный кэш сразу после события, со стороны IIS, либо хранил бы его в memcached и сбрасывал бы ключи чтобы nginx перечитывал. По-моему гораздо проще и не надо демонов обновления городить и анализатор лога
вообще не представляю как это поддерживать :)
но за «KYKY-B-PYKY-U-ATAC» спасибо ))) буду использовать во всех своих проектах!
но за «KYKY-B-PYKY-U-ATAC» спасибо ))) буду использовать во всех своих проектах!
Зачем?
Если можно
Как вы будете задавать несколько серверов?
set $backend 127.0.0.2;
proxy_pass http://$backend;Если можно
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080;
server unix:/tmp/backend3;
}
proxy_pass http://backend;
Как вы будете задавать несколько серверов?
logrotate можно кастомно дёргать по крону со своим конфигом хоть кажую минуту.
По поводу демона для кеша: если у вас девелоперами можно договариться — то самымое простое это чтобы приложение на бэкенде само дёргало урлу для инвалидации кеша. А вообще, да, мемкеш наше всё.
По поводу демона для кеша: если у вас девелоперами можно договариться — то самымое простое это чтобы приложение на бэкенде само дёргало урлу для инвалидации кеша. А вообще, да, мемкеш наше всё.
Хорошая статья. Однозначно в закладки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кеширующий прокси-сервер на nginx. Хитрая конфигурация