Persistent HTTP connections && Pipelining

[MZ]

В ср, 14/11/2007 в 17:05 +0300, Alexey Karagodov пишет:
> 
> 
> 14.11.07, MZ <zuborg at advancedhosters.com> написал(а):
>         В ср, 14/11/2007 в 15:07 +0300, Alexey Karagodov пишет:
>         
>         >
>         >         > А по поводу схемы балансировки по времени ответа
>         очень
>         >         хорошо сказал
>         >         > на РИТе Олег Оболенский из Яндекса - "пятисотки
>         отдаются 
>         >         офигенно быстро".
>         >
>         >
>         > ошибки 5ХХ наверно
>         они, только непонятно почему при балансировке по загрузке они
>         должны
>         возникать чаще чем при балансировке по кол-ву обработанных
>         запросов.
> 
> 
> непонял :)  
непонятно, почему балансировка по нагрузке будут приводить к большим
проблемам, чем балансировка по кол-ву запросов. Но вообще Игорь имел
ввиду что если какий-то бекенд поломается и начнет быстро пулять пустые
200 - на него пойдет весь траф, если балансировать по нагрузке.


> 
> всё гораздо проще. как это сделано на моих площадках: 
> нгинх отдаёт по фастцги на несколько пхп-серверов 
> тайм-аут соединения - 1 с 
> тайм-аут получения ответа - 20 с (скрипты очень тяжёлые на некоторых
> площадках, в идеале надо ставить секунды 4 конечно) 
> так вот, за 5 сек не успел, 5ХХ ошибка получилась, обработали (неважно
> как, повторили запрос на фастцги, нарисовали красивую хтмл-ю
> страничку, что угодно) 
> зачем тут pipelining, keep-alive и пр. красивые и умные слова 
> ну как pipeline с keep-alive-ом тут помогут бекенду? если физически не
> способоен "держать" больше 50 юзеров (к примеру) в секунду с их
> безмерными хотелками 
не у всех сервера неспособны держать больше 50 юзеров (к примеру).
keep-alive поможет быстрым серверам отдавать контент ещё быстрее, вот и
все.
> бекенду - НИКАК. если он МРЁТ, он будет УМИРАТЬ ВСЕГДА 
> тут только одно мне видется, была проблема, когда при раздаче запросов
> нгинх "перебирал" сервера пхп-фастцги и возникала большая куча tcp
> коннектов, сервер отваливался, невозможно было с ним установить новое
> tcp соединение 
> куча коннектов возникала потому, что все сервера пхп были загружены
> запросами по самое небалуйся, а им приходили и приходили новые
> запросы 
> вот тут бы pipelining между nginx и php fastcgi помог бы, но и то,
> ЗАЧЕМ он там?
Тут бы помог keep-alive, а pipelining тут бы все зарубил на корню - если
отправить в затупивший pipeline потенциально быстро обрабатываемый
запрос - будут висеть оба запроса.
> гораздо проще и надёжнее грамотно и красиво (а способов КУЧИ
> несметные) обработать ошибки 5ХХ и не заниматься извратом  
> 
> 
> если проблема в другом, например пхп всегда в определённые границы
> времени вписывается, то начинается проблема с tcp стеком, ну вот хотим
> мы на одном сервере держать 8 к коннектов. но тут надо tcp нормально
> настроить (sysctl) и можно будет спокойно ждать нормальной реализации
> pipelining-а 
зачем 8k коннектов, у вас висит 8k процессов на бекенде ?

>         >         кол-ву запросов в обработке бекендом. А не
>         балансировать по 
>         >         кол-ву
>         >         запросов вообще, как сейчас.
>         >
>         >
>         > если только косвенно определить, сколько отдали запросов,
>         сколько
>         > получили, разница и будет показателем примерной
>         загруженности 
>         > если чего на бекенде не случится
>         Эта разница равна кол-ву запросов, которые бекенд обрабатывает
>         в данный
>         момент, верно ? 
> 
> 
> примерно так (в штатной ситуации - точно так). точную цифру может
> сказать только сам бекенд, при условии, что он этим функционалом
> обладает 

То есть nginx понятия не имеет, к скольки бекендам  (вернее, сколько
раз) он сейчас подключился и отправил запрос, Вы это хотите сказать ?