Оно мне нигде ничего не даст. С вероятностью 99.9(9) запрос будет
отослан. Вероятность того что НЕ будет, это nginx сломается.
Кроме того, как я писал, большущщая, просто огромная проблема в том что
бекенд пока на вендах. Линукс переваривает 15-20 тысяч тайм вейт
сокетов, ему конечно не очень хорошо... Венде "капец" при подобной
загруке. Увеличением количества процессоров не лечится. Будет достаточно
скооро вылечено переводом бекенда на линукс, но и ему не очень хорошо.
Персистент конекшен спасе бы даже венду.
Andrey Ryabushenko wrote:
Там же вманауле написано, чтобы уменьшить кол-во используемых сокетов, причём
именно засчёт снижения сокетов в состоянии TIME_WAIT.
Что это такое теперь понял, а вот зачем такое может понадобится нет.
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 секунд. Помогает но не сильно.
За "персистент" конекты к бекенду готов даже бетту в продакшн
выставить.