ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ограничение соеди нений с backend



Апачу плохеет не от того что соединений много, а от того что нагрузка превышает возможности сервера - и это является причиной большого числа соединений, а не наоборот. Уменьшить нагрузку на апач директавами в nginx.conf невозможно, максимум что можно сделать это улучшить работу одних запросов посредством игнорирования остальных, но этот как лечить насморк гильотиной.

Оптимизируйте работу апача и скриптов, чтоб создавали меньшую нагрузку на том же наборе запросов. Кеширование в частности рулит в любом виде.

Vladimir Latyshev wrote:
В архиве нашел подобную тему, но решение неясно.

Как известно, apach'у плохеет при большом количестве соединений. Предположим, нагрузочным тестированием выявлено, что некий сервис на apache+php тянет 100 одновременных обращений, а при большей нагрузке - ложится. MaxClients ставим на сотню, но лишние соединения все равно приходят, висят в очереди (ListenBacklog), и де-факто получаем для всех 100% клиентов слишком долгое ожидание. Как побороть это в апаче - так и не придумал. Хочется сделать так, чтобы те, кому "повезло" получали ответ быстро сразу, а остальные - вежливый отлуп (еще быстрее, хехе).

Возможно ли с помощью nginx ограничить глобально число активных соединений с бэкэндом при использовании директивы proxy_pass, а всем "лишним" выдавать некую статику?
Можно попробовать выкрутиться так:

limit_zone conn $myvar 100k;
set $myvar 1; # константа, то есть ограничение для всех (глобально)
limit_conn conn 100;
error_page  503 =200 /sorry.html;

Но этот вариант не устраивает, так как медленные соединения заблокируют доступ остальным, а апач будет по сути простаивать. Что еще можно придумать? Подозреваю, что я не первый задаюсь этим вопросом и решение уже существует :)




 




Copyright © Lexa Software, 1996-2009.