ПРОЕКТЫ 


  АРХИВ 


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: Keep ALive for backend



Ответы по тексту.

На счет persistent connection. Еще один довод.
Есть очень большое желание поставить несколько проксирующих серверов на разных континетах. При таком раскладе есть возможность выбрать провайдера у которого максимальная скорость соединения с основным сервером, у клиентов такой возможности дефакто нет. Но, если открывать
каждый раз сокет из NY в Токио, хорошего будет мало.

Если нужно более детальное объяснение работы системы, то можно "в личку".

Igor Sysoev wrote:
On Fri, Nov 09, 2007 at 11:15:22AM +0300, Kostya Alexandrov wrote:

Поможет. Основная беда это то что java.io очень медленно акцептает соединения.
А насколько медленно - сколько запросов в секунду он может обработать с ответом типа 
"hello world!" ?

500-600 на ХР, до 1000 на 2003 (там беклог больше), до 1200 на линуксе. это в среднем.

Относительно сносно эту задачу решал mod_wl для апача, но там
1. нет сырцов и не полностью ясно как он работает, не всегда так как это описывает документация. 2. Apache не может держать даже 2000 Keep-Alive соединений. Ему для каждого нужен процесс/поток
в зависимости от worker/prefork. Точнее он впринципе их держит, но печально.

А как работала схема с Апачём - где использовался keep-alive -
с клиентом и бэкендом или только с бэкендом ?

И там и там. Но. Капалив часто закрывается по таймауту.
Апач на каждое кипаливное соединение держит поток, соответственно из каждого
потока *возможно* открытие соединения с weblogic, но клиент может и неуложится в таймаут. Увеличение таймаута приводит к перерасходу ресурсов как на апаче так и на weblogic.
это тысячи соединений и тысячи потоков. и становится совсем печально.
Максимальный беклог могу поставить 2000, больше игнорирует.

Игнорируется на каком уровне - сервер, ОС ?

Документация говорит о 2000. Пробовал ставить больше - ситуации не исправляет. Кто обрезает точно незнаю. Поведение дурное. Он в течении 2-3 минут может обслужить 2000 и больше, а потом отпадет
на несколько секунд и не будет принимать совсем.
Igor Sysoev wrote:
On Fri, Nov 09, 2007 at 10:44:00AM +0300, Kostya Alexandrov wrote:

Много раз обсуждался вопрос реализации keep-alive для бэкенд сервера.
Хотел бы попросить еще раз о реализации.

Суть проблемы.

nginx используется как прокси для Weblogic 7 - довольно дремучая версия, с кучей проблем,
но пока от нее избавится не удается, legacy system.
Все работате очень хорошо, и в отличии от Apache2, nginx великолепно справляется с нагрузкой.

Система устроена так, что клиенты запрашивают изменения каждые 2 секунды, потому даже 1000-1500 клиентов уже очень серьезно. На таких объемах начинает умирать сервлетный движок weblogic. Переодически Connection Refused. Он не может accept новые соединения, увеличение backlog сильно не помогает. дальше увеличивать уже некуда. Так на 400-500 пользователях появился апач перед weblogic. На 1200 Apache сдался и не смог держать Keep-Alive. Сейчас работает nginx. Проблем с загрузкой процессора, keep-alive etc нет, но проблема connection refused осталась. Кроме запроса обновлений клиенты послыют другие команды, при 1500 клинтов примено 2000-2200 http запросов в секунду.

Если бы можно было как то лимимитировать количество одновременных запросов к бекенду и держать keep-alive с бекендом, то было бы очень здорово, или хотябы держать keep-alive с бекендом.

Есть идея писать свой fast-cgi, но мало опыта, заняты разработкой другой системы коммуникаций, но
количество клиентов увеличивается.
Я не вижу, как keep-alive поможет существенно улучшить эту ситуацию.
Если поставить большой backlog - например, 20,000, то соединения от nginx'а
будут в нём накапливаться и жить максимум до 75 секунд. Эту будет
близко к ограничению соединий с таймаутом 75 секунд.






 




Copyright © Lexa Software, 1996-2009.