ПРОЕКТЫ 


  АРХИВ 


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: Persistent connnection


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: Persistent connnection
  • From: "Alexey V. Karagodov" <karagodov@xxxxxxxxx>
  • Date: Fri, 21 Dec 2007 18:11:47 +0300
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=5IoD74p1F/aMQtTAryS8fNmnn6U+btgJItMyKSit9zY=; b=mDXp8x0ek0bQjfMNfsu6FeyBPC0QvP6zHmomS1Jm2kCTIFKZD9iaEsVipfwv05V2lPanrAWj4aLNu1VuWVX29gM65sIsuC//qerukCd+hj9TVZcAyMVp+T9XXHaOkl3TXL1+TtN5EsFUytPaj03wUVhRD99NiEdm2YHUCT7aib0=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=YR6Y16ASfjmAgEQaJJ5y840dZtEZDGcrg5bBMUpNBgPpu11f3z3s6cLzQKNpQ9Joj+KLOgpvOLniFF2HIpVe78sYAjmoxE2YFDn+IY7dmBJJS++qhpk5GZ8T8mv5JIb04FlszAVXNlLQIWAZefmhklDEJRjoN1+l0zocrEzR+Io=
  • In-reply-to: <476BC6A3.90901@xxxxxxx>
  • References: <02ba01c840b1$5be59220$5801a8c0@cp01> <200712191954.20366.cdome@xxxxx> <476A6255.7040000@xxxxxxx> <200712201759.50203.cdome@xxxxx> <476BC6A3.90901@xxxxxxx>

persistent соединение к чему?

для уменьшения TIME_WAIT  надо снижать тайм-ауты и пр (ковырять sysctl)
там немного
пример прислать?

On 21.12.2007, at 16:58, Kostya Alexandrov wrote:

Оно мне нигде ничего не даст. С вероятностью 99.9(9) запрос будет отослан. Вероятность того что НЕ будет, это nginx сломается. Кроме того, как я писал, большущщая, просто огромная проблема в том что бекенд пока на вендах. Линукс переваривает 15-20 тысяч тайм вейт сокетов, ему конечно не очень хорошо... Венде "капец" при подобной загруке. Увеличением количества процессоров не лечится. Будет достаточно скооро вылечено переводом бекенда на линукс, но и ему не очень хорошо. Персистент конекшен спасе бы даже венду.

Andrey Ryabushenko wrote:
Там же вманауле написано, чтобы уменьшить кол-во используемых сокетов, причём именно засчёт снижения сокетов в состоянии TIME_WAIT.

В nginx включается очень просто
http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#listen
Часть про accept_filter.

Но тебе он на бекенде нужнее, чем на фронтенде.

В сообщении от 20 декабря 2007 14:38 Kostya Alexandrov написал(a):

Что это такое теперь понял, а вот зачем такое может понадобится нет.

Andrey Ryabushenko wrote:

http://www.freebsd.org/cgi/man.cgi?query=accf_http

Фильтр не даст приложению соединение пока на нем не покажется полностью законченный HTTP запрос. Приложению не приходится ждать запроса с сокета,
что и создано для того чтобы приложение получало сокет когда он ему
нужен, а не в состоянии TIME_WAIT и потом жди у моря погоды когда же
запрос наконец-то появится.

В сообщении от 19 декабря 2007 13:57 Kostya Alexandrov написал(a):

А можно поинтересоваться что это такое и как это может помоч?

Andrey Ryabushenko wrote:

IMO тебе здесь надо http_accept_filter включить, прич ём как на nginx так и на бэкенде, и этого вполне может хватить для решения проблемы.

В сообщении от 17 декабря 2007 22:22 Kostya Alexandrov написал(a):

Поднимаю тему опять. Паплайнинг уже не прошу, не надеюсь.
Проблемы с медленными акцептами на яве решили. Написанием собственного
маленького http servlet engine.
Работает замечательно.

Но ничего не могу сделать с TIME_WAIT сокетами. Если бекенд на
линуксе, то еще хоть как то жизненно, tcp_tw_recycle, tcp_tw_reuse для локального нетворка можно использовать, для глобальной сети (клиенты
из интернета) чревато чудесами. Всеровно тормозит когда сокетов
в time_wait становится около 10К.

Однако если бекенд на "венде" то полный привет... 18К сокетов в
time_wait, тормозит....
TcpTimedWaitDelay скручен в 30 секунд. Помогает но не сильно.

За "персистент" конекты к бекенду готов даже бетту в продакшн
выставить.





 




Copyright © Lexa Software, 1996-2009.