Re: freebsd+nginx+php-fpm

[Gena Makhomed <gmm@xxxxxxxxx>]

On Friday, June 19, 2009 at 16:56:28, Andrei Nigmatulin wrote:

AN>>> В случае всплесков мне нужно пытаться обслужить клиента до последнего и 
мне
AN>>> бесполезна возможность моментально узнать что backend загружен под 
завязку.

>> Вы видели хотя бы одного клиента который будет сидеть
>> перед монитором и ждать ответ от сервера например, 60 секунд ?
>> обычное больше 5-15 секунд не ждут.

AN> 5-15 отличное время, чтобы посидеть помедитировать на строчку "Waiting for
AN> reply...". Так будет делать средний пользователь, если ему не показывать
AN> error_page 502. Если показывать - будут часто рефрешить. Что вы выигрываете,
AN> если backend не отвечает, а запросов на фронтенд стало в несколько раз 
больше
AN> из-за этих refresh ?

получив сообщение об ошибке - сможет чаще рефрешить, это правда.
но долго ли ему захочется заниматься таким бесполезным занятием?
я, например, только 2-3 раза пробую открыть сайт, если не получается - ухожу.
больше 5-10 попыток открыть не открывающийся сайт пользователь вряд-ли сделает.

что выигрываем:

1. backend успеет обработать поставленные в очередь запросы за приемлимое
время и frontend сможет отправить нормальные ответы всем этим клиентам.
клиент скорее всего дождется ответа от сервера, ждать надо будет не долго.

если frontend будет достаточно долго пытаться подключиться к backend`у -
это у него может получиться и backend даже обработает этот запрос и выдаст
ответ. но в тот период времени, когда frontend начал принимать ответ от 
backend`а
или отдавать его клиенту - у клиента может закончиться терпение и он нажмет F5,
что будет означать работу backend`а вхолостую для некоторой части запросов.

по моему скромному мнению, процент клиентов получивших 200 ответ от backend`а
на свой запрос в схеме с 502-й ошибкой будет больше, чем во втором варианте.

2. получив 502-ю ошибку от backend`а, frontend может выдать клиенту 503-ю
ошибку "Service Unavailable" с заголовком Retry-After: 3600, по крайней мере,
запросы от поисковых ботов можно будет отложить во время пиковой 
нагрузки/аварии.
http://groups.google.com/group/Google_Webmaster_Help-Indexing/msg/bc49ca084f7e79c7
( в момент написания этого сообщения Mark Berghausen был сотрудником Google )

3. 503-й ответ - статика, кэшируется в памяти frontend`а и небольшой по размеру.
в ситуации когда все backend`ы перегружены запросами, - некоторое увеличение
количества запросов на frontend (даже в 2-3 раза) - это нормально, frontend
справится. по крайней мере, frontend`ы масштабировать проще чем backend`ы.

4. получив от backend`а 502-й ответ frontend сможет отправить
клиенту несколько устаревший ответ из кэша, что может быть лучше,
чем не возвращать вообще ничего или возвращать сообщение об ошибке.

5. возврат клиенту 503-й ошибки более соответствует RFC-стандартам,
чем долгий "Waiting for reply..." и последующий "Network Timeout".

AN> Я прошу прощения, но отвечать в рассылку вам больше не буду - устал.
AN> Мне кажется, что свою точку я изложил более чем развернуто,
AN> и если это кому-нибудь пригодится, то задача спора выполнена.

спасибо за потраченное время и полезную информацию.

-- 
Best regards,
 Gena