ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Так в том-то все и дело, что оба сервера (старый и новый) выступают
ssl-клиентами! SSL-сервером выступает железка с хардварным
криптопроцессором. На обоих ssl-клиентах запускается одна и та же
команда и старенькая железка с BSD по относительной производительности
быстрее на порядок! Cipher у обоих ssl-клиентов в момент теста
одинаковый - AES256-SHA. На linux-ssl-клиенте есть прямая зависимость
количества сгенерированных клиентских ssl-сессий от количества форков
программы-флудера: один форк - ~1024 соединения, 10 форков - 10232
соединения. Возникает ощущение какого-то ограничения.

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
>
>


 




Copyright © Lexa Software, 1996-2009.