Keep ALive for backend

Kostya Alexandrov koticka at mail.ru
Fri Nov 9 12:01:08 MSK 2007


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

На счет 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 секунд.
>>>
>>>
>>>  
>>>       
>
>   





More information about the nginx-ru mailing list