Re: соотношение балансировщиков/веб-серверов (оффтоп, но...)

[big bond]

27 октября 2009 г. 13:24 пользователь Igor Sysoev <is at rambler-co.ru> написал:
> On Tue, Oct 27, 2009 at 12:22:17PM +0300, big bond wrote:
>
>> 26 октября 2009 г. 23:35 пользователь Igor Sysoev <is at rambler-co.ru> написал:
>> > On Mon, Oct 26, 2009 at 11:04:53PM +0300, big bond wrote:
>> >
>> >> Согласен, но все же я пытаюсь определить, при каком количестве
>> >> конкурентных SSL-сессий умрет балансировщик. Тесты показали, что в
>> >> случае если SSL терминируется на apache, то количество ESTABLISHED на
>> >> стороне клиента ~= количеству worker'ов apache (в тесте был 1 клиент и
>> >> 1 сервер), причем с точностью до нескольких штук на тысячи соединений.
>> >> Как точно посчитать количество SSL-handshake'ов?
>> >
>> > $ab -? 2>&1 | tail -2
>> >    -Z ciphersuite  Specify SSL/TLS cipher suite (See openssl ciphers)
>> >    -f protocol     Specify SSL/TLS protocol (SSL2, SSL3, TLS1, or ALL)
>> > $
>> >
>> > как бы говорит нам, что оно умеет и HTTPS.
>> Да, но:
>> $man ab:
>> <--------->
>>        -s     When compiled in (ab -h will show you) use the SSL
>> protected https rather than the http protocol. This feature is
>> experimental and very rudimentary. You probably do not want to use it.
>> <--------->
>
> Но попробовать-то это не мешает. Всяко лучше, чем flood_connect, который
> не меряет вообще ничего. Можно попробовать httperf:
>
>       httperf --hog --server=www --wsess=10,5,2 --rate=1 --timeout=5 --ssl
>              Like above, except that httperf contacts server www via  SSL  at
>              port 443 (the default port for SSL connections).
>
Спасибо, попробую httperf, но я не уверен, что он сможет сгенерировать
с одной десктоп-машины хотя бы пару десятков тысяч параллельных
соединений (как это может flood_connect, но это решается
дополнительными железками, в принципе), зато уж точно будут
полноценные хендшейки + http запросы как бонус, хотя на данном этапе
меня интересуют "чистые" ssl-сессии, без передачи данных внутри них.
Причина проста - мы подверглись массированной атаке на текущие
балансировщики (apache, балансируют + терминируют ssl) - тысячи пустых
ssl-сессий заставили индейца породить тысячи worker'ов и они съели всю
память.
>
> --
> Игорь Сысоев
> http://sysoev.ru
>
>