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

[big bond <bondarets@xxxxxxxxx>]

26 октября 2009 г. 23:35 пользователь Igor Sysoev <is@xxxxxxxxxxxxx> написал:
> 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.
<--------->
>
>> 26 октября 2009 г. 22:12 пользователь Igor Sysoev <is@xxxxxxxxxxxxx> написал:
>> > On Mon, Oct 26, 2009 at 10:02:58PM +0300, big bond wrote:
>> >
>> >> Подскажите кто-нибудь все же, как лучше всего оценивать количество
>> >> соединений в состоянии ESTABLISHED когда сервер нагружен значительно?
>> >> netstat действительно вносит погрешность, т.к. сам отнимает много
>> >> ресурсов на выполнение.
>> >
>> > Число SSL-handshake'ов бессмысленно определять по ESTABLISHED.
>> >
>> >> 23 октября 2009 г. 11:31 пользователь Igor Sysoev <is@xxxxxxxxxxxxx> 
>> >> написал:
>> >> > On Fri, Oct 23, 2009 at 11:26:47AM +0400, big bond wrote:
>> >> >
>> >> >> сам flood_connect ничего не показывает (если не ограничить его опцией
>> >> >> -n число_соединений), я запускаю netstat в момент атаки:
>> >> >> while true;do netstat -tn | grep EST | grep -c 443;sleep 5;done
>> >> >> и смотрю, что набегает, на данный момент интересуют именно ESTABLISHED
>> >> >> соединения, до rate-тестов еще не добрались.
>> >> >
>> >> > И долго эти соединения висят ? Если долго, то всё упрётся в 64K 
>> >> > локальных
>> >> > портов, а если нет, то при измерении netstat/sleep огромные погрешности.
>> >> > В общем, пока измеряем цену апельсинов.
>> >> >
>> >> >> Я нашел-таки узкое место. Все-таки это был ulimit -n, он почему-то
>> >> >> периодически возвращается к дефолту в 1024, хотя машина не
>> >> >> перезагружалась уже несколько месяцев (видимо при логине
>> >> >> сбрасывается). Может кто подскажет, как это в линуксе победить? ulimit
>> >> >> на пользователя вроде как выставляется, для некоторых программ я
>> >> >> помещал команду типа ulimit -n 4096 в стартовый init-скрипт, но как
>> >> >> это сделать для рута? В /etc/security/limits.conf я не вижу подобной
>> >> >> опции:
>> >> >> #<item> can be one of the following:
>> >> >> #        - core - limits the core file size (KB)
>> >> >> #        - data - max data size (KB)
>> >> >> #        - fsize - maximum filesize (KB)
>> >> >> #        - memlock - max locked-in-memory address space (KB)
>> >> >> #        - nofile - max number of open files
>> >> >> #        - rss - max resident set size (KB)
>> >> >> #        - stack - max stack size (KB)
>> >> >> #        - cpu - max CPU time (MIN)
>> >> >> #        - nproc - max number of processes
>> >> >> #        - as - address space limit
>> >> >> #        - maxlogins - max number of logins for this user
>> >> >> #        - maxsyslogins - max number of logins on the system
>> >> >> #        - priority - the priority to run user process with
>> >> >> #        - locks - max number of file locks the user can hold
>> >> >> #        - sigpending - max number of pending signals
>> >> >> #        - msgqueue - max memory used by POSIX message queues (bytes)
>> >> >> #        - nice - max nice priority allowed to raise to
>> >> >> #        - rtprio - max realtime priority
>> >> >>
>> >> >> Какая из них отвечает за ulimit -n ? Наиболее похожа -locks, но не 
>> >> >> вполне.
>> >> >>
>> >> >> 23 октября 2009 г. 10:58 пользователь Igor Sysoev <is@xxxxxxxxxxxxx> 
>> >> >> написал:
>> >> >> > On Fri, Oct 23, 2009 at 10:13:32AM +0400, big bond wrote:
>> >> >> >
>> >> >> >> Так в том-то все и дело, что оба сервера (старый и новый) выступают
>> >> >> >> ssl-клиентами! SSL-сервером выступает железка с хардварным
>> >> >> >> криптопроцессором. На обоих ssl-клиентах запускается одна и та же
>> >> >> >> команда и старенькая железка с BSD по относительной 
>> >> >> >> производительности
>> >> >> >> быстрее на порядок! Cipher у обоих ssl-клиентов в момент теста
>> >> >> >> одинаковый - AES256-SHA. На linux-ssl-клиенте есть прямая 
>> >> >> >> зависимость
>> >> >> >> количества сгенерированных клиентских ssl-сессий от количества 
>> >> >> >> форков
>> >> >> >> программы-флудера: один форк - ~1024 соединения, 10 форков - 10232
>> >> >> >> соединения. Возникает ощущение какого-то ограничения.
>> >> >> >
>> >> >> > А какие цифры на старой машине у одного форка и у 10 ?
>> >> >> > И что вообще показывает flood_connect - число установленных 
>> >> >> > соединений
>> >> >> > в секунду или что ?
>> >> >> >
>> >> >> >> 23 октября 2009 г. 9:50 пользователь Igor Sysoev <is@xxxxxxxxxxxxx> 
>> >> >> >> написал:
>> >> >> >> > On Thu, Oct 22, 2009 at 11:37:24PM +0400, big bond wrote:
>> >> >> >> >
>> >> >> >> >> В описанном мной тесте nginx не участвовал. Было 2 разных
>> >> >> >> >> *нагружающих*сервера  - старое железо с FreeBSD и новый сервер с
>> >> >> >> >> Linux. Нагружали
>> >> >> >> >> балансировщик (мощная железка, полностью аппаратное решение на
>> >> >> >> >> FPGA-вентилях). Удивило то, что очень старый сервер с BSD смог 
>> >> >> >> >> сгенерировать
>> >> >> >> >> всего лишь вдвое меньше конкурентных SSL-сессий, чем весьма 
>> >> >> >> >> неслабый сервер
>> >> >> >> >> под Linux (7500 у 1xP3 700 против 16000 у 2xXEON 2500).
>> >> >> >> >
>> >> >> >> > SSL-handshake со стороны клиента быстрее раз в 10-20, чем на 
>> >> >> >> > серверной
>> >> >> >> > стороне:
>> >> >> >> >
>> >> >> >> > Pentium M 1.7GHz:
>> >> >> >> > openssl speed rsa1024
>> >> >> >> > ...
>> >> >> >> > Doing 1024 bit private rsa's for 10s: 2401 1024 bit private RSA's 
>> >> >> >> > in 9.97s
>> >> >> >> > Doing 1024 bit public rsa's for 10s: 49828 1024 bit public RSA's 
>> >> >> >> > in 9.92s
>> >> >> >> >
>> >> >> >> > AMD Athlon64 3500+ 2.2GHz:
>> >> >> >> > openssl speed rsa1024
>> >> >> >> > ...
>> >> >> >> > Doing 1024 bit private rsa's for 10s: 11318 1024 bit private 
>> >> >> >> > RSA's in 9.99s
>> >> >> >> > Doing 1024 bit public rsa's for 10s: 237965 1024 bit public RSA's 
>> >> >> >> > in 9.96s
>> >> >> >> >
>> >> >> >> > Сервер делает операцию private RSA, а клиент - public. Кстати, из 
>> >> >> >> > этого
>> >> >> >> > теста видно, что для SSL лучше использовать 64-битные платформы: 
>> >> >> >> > RSA
>> >> >> >> > быстрее в 4-5 раз.
>> >> >> >> >
>> >> >> >> >> 22 октября 2009 г. 23:12 пользователь Gena Makhomed 
>> >> >> >> >> <gmm@xxxxxxxxx> написал:
>> >> >> >> >>
>> >> >> >> >> > big bond wrote:
>> >> >> >> >> >
>> >> >> >> >> >  Кстати, сегодня пробовали нагрузить конкурентными 
>> >> >> >> >> > SSL-сессиями один из
>> >> >> >> >> >> тестирумых балансировщиков, использовали программу 
>> >> >> >> >> >> flood_connect. Я
>> >> >> >> >> >> скомпилировал её на линуксовой машине (2хXEON E5420, 2.50GHz, 
>> >> >> >> >> >> 4GB RAM, SUSE
>> >> >> >> >> >> ENT 10.2), выжать смог максимум 16000 соединений, все 4 ядра 
>> >> >> >> >> >> были загружены
>> >> >> >> >> >> на 100%.
>> >> >> >> >> >> Коллега скомпилировал на старенькой железке (P3 700MHz, 512MB 
>> >> >> >> >> >> RAM, FreeBSD
>> >> >> >> >> >> 7.2), выжал 7500 соединений и процессор был загружен не более 
>> >> >> >> >> >> 80%!!!!
>> >> >> >> >> >> Сам балансировщик при этом тоже неплохо был загружен.
>> >> >> >> >> >> Как такое возможно? Старая железка отстала всего в два раза от
>> >> >> >> >> >> современного неслабого сервера!
>> >> >> >> >> >> Запускали так: *flood_connect -S -f 10 -p 443 
>> >> >> >> >> >> /адрес_балансировщика/*
>> >> >> >> >> >> -f - количество форков
>> >> >> >> >> >> -S - SSL-режим
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > 1. если включить ssl_session_cache -
>> >> >> >> >> > SSL будет работать намного быстрее.
>> >> >> >> >> > например:
>> >> >> >> >> >
>> >> >> >> >> > http {
>> >> >> >> >> >    ssl_session_cache  shared:SSL:20M;
>> >> >> >> >> >    ssl_session_timeout 120m;
>> >> >> >> >> >    ...
>> >> >> >> >> >
>> >> >> >> >> > почему ssl_session_cache по умолчанию выключен -
>> >> >> >> >> > не знаю, наверное чтобы зря не расходовать память,
>> >> >> >> >> > если SSL не используется или используется очень мало.
>> >> >> >> >> >
>> >> >> >> >> > 2. если при сборке nginx указывать ключи
>> >> >> >> >> > --with-md5-asm --with-zlib-asm=pentiumpro
>> >> >> >> >> > думаю что он тогда будет работать быстрее,
>> >> >> >> >> > чем если без них. по крайней мере, на i386.
>> >> >> >> >> >
>> >> >> >> >> > см. также другие ключи оптимизации в ./configure --help
>> >> >> >> >> > все не используемые модули наверное лучше будет выключить.
>> >> >> >> >> >
>> >> >> >> >> > 3. если при работающем nginx изменялись SSL сертификаты
>> >> >> >> >> > в конфиге - тогда надо делать service nginx force-reload
>> >> >> >> >> > потому что после service nginx reload - nginx продолжает
>> >> >> >> >> > использовать старые и молча игнорирует новые сертификаты.
>> >> >> >> >> >
>> >> >> >> >> > я не считаю, что это ошибка, - это больше особенность поведения
>> >> >> >> >> > о которой следует помнить, если приходится их на лету 
>> >> >> >> >> > обновлять.
>> >> >> >> >> >
>> >> >> >> >> >     По хорошему надо CARP, но в принципе достаточно просто    
>> >> >> >> >> > чтоб в одном
>> >> >> >> >> >> vlan-е были, вручную IP слегшего сервера можно будет 
>> >> >> >> >> >> перекинуть.
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > в англоязычном списке рассылки на вопрос про балансировщики
>> >> >> >> >> > советовали использовать http://www.backhand.org/wackamole/
>> >> >> >> >> >
>> >> >> >> >> > и читать книжку Scalable Internet Architectures
>> >> >> >> >> >
>> >> >> >> >> > http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Игорь Сысоев
>> >> >> >> > http://sysoev.ru
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Игорь Сысоев
>> >> >> > http://sysoev.ru
>> >> >> >
>> >> >> >
>> >> >
>> >> > --
>> >> > Игорь Сысоев
>> >> > http://sysoev.ru
>> >> >
>> >> >
>> >
>> > --
>> > Игорь Сысоев
>> > http://sysoev.ru
>> >
>> >
>
> --
> Игорь Сысоев
> http://sysoev.ru
>
>