Илья, огромное спасибо за то, что так подробно ответили и проявили интерес!
Запуск намечаем на сегодня ;-)
Ну а теперь подробнее, и в самом конце приведу свой полный конфиг
> 22 августа 2012 г., 2:04 пользователь ShivaS <nginx-forum@xxxxxxxx>
> написал:
>
> > Добрый вечер,
> >
> > Возникла интересная возможность применения nginx в очень нагруженном
> > проекте.
> >
> > Мы активно пользуемся Амазонон (ЕС2) и соответственно лоад
> балансером ELB,
> > который на данном этапе делает оффлоад на SSL и общается с пуш
> серверами.
> > Сервис достаточно большой, и на определенном этапе мы поняли, что
> ELB
> > перестал справляться с нагрузкой, да и его вечное отсоединение
> соединений с
> > пуш серверами уже надоело.
> >
> > Провели тестирование с nginx на одном из серверов в амазоне, которое
> > показало неплохие результаты, но все уперлось в память.
> > Значит надо много серверов с большим кол-вом памяти. На удивление,
> несмотря
> > на SSL, процессоры вообще не напрягались и LA постоянно оставался <
> 1, что
> > дает возможность брать сервера с большим кол-вом памяти, малым
> кол-во
> > процессоров и экономить.
> >
>
> LA = Load Average, это показатель, который соответствует количеству
> процессов, ожидающих ввода-вывода. При высокой дисковой нагрузке,
> соотвественно упирается в потолок. В случае терминации SSL он и не
> должен расти больше единицы.
>
Ну насколько я понимаю LA не обозначает именно дисковые проблемы, а любую
проблему (и не обязательно проблему) с ожиданием процессоров. При 8 воркерах
я и ожидал около 8 в какой-то момент, так как боялся тормозов установки SSL
сессии и, что SSL поест процессоры без разбору. Но видимо все обошлось и,
как Вы написали, логично получил <1. Видимо я не до конца осознал всю
глубину глубин ;-)
> >
> > Система: CentOS 6; nginx 1.2.3
> >
> > конфиг подправлял в паре мест.
> > Вот тут:
> >
> > listen *:443 default backlog=4096 so_keepalive=30m::10;
> >
> > И еще немного тут:
> >
> > worker_processes 8;
> > worker_rlimit_nofile 204800;
> >
> >
> > events {
> > worker_connections 20000;
> > use epoll;
> > multi_accept on;
> > accept_mutex on;
> > }
> >
>
>
> серьезный момент - сколько запросов делает один клиент ? если
> несколько (в
> нашей ситуации в среднем 5), то очень серьезный выигрыш получается за
> счет
> keepalive до клиента (у вас он не включен).
>
> в SSL очень дорогой хендшейк, он идет на несимметричной криптографии,
> keepalive позволяет уменьшить количество дорогих хендшейков. реально,
> CPU
> падает в разы (если один клиент делает несколько последовательных
> запросов
> и они попадают в одну keepalive-сессию)
>
>
Запросов может быть очень много. Есть клиенты которые подсоединяются и в
силу своих крутых интернетов остаются висеть "на связи", а есть такие,
которые постоянно отваливаются и передподсоединяются. С ними вот и много
траблов в основном. Речь о мобильниках, точнее смартфонах. Соединение идет
одно. Это не бразуеры с декстопов, которые любят пооткрывать много чего с
самого начала.
Т.е. получается клиент либо подсоединился и висит, ожидая пуша, либо
отвалился и пробует переподсоединиться, и тогда возможно упадет снова на тот
же сервер, где ему ssl_session_cache и поможет осуществить задуманное в
краткие сроки ;-)
> >
> > Стоит ли ставить много воркеров и малое кол-во коннекшенов на каждый
> или
> > достаточно один и сразу выставить максимальное кол-во подсоединений?
> Диски
> > не задействованы совсем.
> >
>
> один воркер может задействовать одно ядро. если воркеров меньше, чем
> ядер,
> то сервер будет недонагружен.
>
> с другой стороны, если у вас интенсивно используются механизмы,
> требующие
> согласования воркеров между собой (например limit_req), то может быть
> оверхед на согласование.
>
> трассируйте, смотрите :-)
>
>
Нет, ничего такого не используется. Просто SSL оффлоадер с пуш серверами в
бекенде.
Я 8 так и оставил, просто думал что может памяти чуть отгрузить, раз
процессоры недогружены, а каждый воркер берет по сотке МБ.
Но наверно не стоит.
>
> > Приведенные выше настройки использовались на сервере с 7ГБ памяти.
> > каждый воркер берет память, а при 60кб на клиент, даже несколько
> сотен
> >
>
> версия nginx какая ? недавно пробегал патч (включенный в последние
> версии),
> отключающий компрессию на уровне SSL, заметно снижающий потребление
> памяти.
>
>
Я изначально написал, что 1.2.3, но хитро спрятал в конце предложения ;-)
Т.е. взял самую последнюю стабильную. Да, я читал про отмену сжатия и
очистку памяти от старых подсоединений. Или что-то около того ...
> > мегабайт при большом кол-ве серверов может дать некоторый выигрыш.
> >
> > Использую ssl ciphers AES256-SHA, для относительной надежности и
> скорости.
> >
>
> современные процессоры умеют AES-NI инструкции, в openssl они есть
> начиная
> с 1.0.1 (или чуть раньше ?). мы такое тестили - отвал башки, в
> продакшен
> скоро будем запускать. на амазоне - не знаю, там же Xen ? посмотрите
> на
> /proc/cpuinfo, светится там AES ?
>
>
Вроде как не светится:
flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2
ss ht syscall nx lm rep_good aperfmperf unfair_spinlock pni ssse3 cx16
sse4_1 sse4_2 popcnt hypervisor lahf_lm dts
На самом деле я взял AES256-SHA еще и потому, что он используется на самом
балансере амазона (ELB), т.е. хотел сделать идентичное с нгинкс для более
четкого сравнения.
> >
> > стоит ли ставить OpenSSL 1.0.1? ECDHE не пользуем, да и тормознутый
> он
> > (судя
> > по бенчмаркам, которые мы гоняли) и в скорости обработки
> подсоединений и в
> > объеме потребляемой памяти. Кроме этого, никаких преимуществ особо
> не нашел
> > в 1.0.1
> >
>
> в 1.0.1 есть аппаратное ускорение AES.
>
> ECDHE - не более тормознутый, он быстрее за счет того, что
> эллиптическая
> криптография обеспечивает сопоставимую сложность при меньших ключах.
> вы
> случайно не такого же размера ключи выбирали ?
Что-то вот тут я не понял. Сертификат 2048 bit, это Вы имели в виду?
Остальное я ничего не выбирал...ну или не совсем понимаю вопроса.
навскидку, на эллиптических кривых длину ключа можно делить на три и будет такая же криптографическая сложность, как для традиционной криптографии. если и там и там делать по 2048, то, конечно, ECDHE втупит на тестах :-)
>
> у ECDHE минус в том, что он пока не очень поддерживается на стороне
> клиента. но не в производительности.
>
>
Я еще читал про патч от Гугла который это дело разгоняет нехило, ЕСС, но
вроде там какие-то траблы с лицензией, только в определенных страннах
использовать и т.д..
Я в принципе пока и не рискую этим пользоваться, потестировал, посмотрел,
память съелась ну и решил сделать идентично с ELB
Основная проблема в этих вечно отваливающихся клиентах и ELB таймаутах.
Таймауты то решиться должны вроде, а вот с отваливанием клиентов посмотрим,
когда будет продакшен. iDevices и Андроиды работают без этого сервиса,
напрямую TCP. А вот для всех остальных терминация сервиса идет по https,
возможно не везде я что-то правильно выбрал и не все девайсы индо-китая
могут поддержать то, что я им навязываю. Ну и BB и Win7 phone тоже сюда,
хотя они четко работают и не отваливаются.
>
> > Может, там что-то и подкручено, но меня интересует в основном
> потребление
> > памяти, а разницы с 1.0 в тестах не заметил
> >
> > Кеш выставил, но шансы что клиент переподсоединиться на тот же
> сервер -
> > минимальны, но сотню мегов не жалко ;-)
> >
>
> ssl_session_cache ?
> в приведенном конфиге ее нет.
> покажите полный конфиг ?
>
Да, укажу его в самом конце.
> >
> > ну и sysctl соответственно тоже.
> >
> > Сейчас вот подумываем очень серьезно о полном переходе на nginx в
> качестве
> > основного оффлоадера.
> >
>
> какая у вас нагрузка ?
> мы держим 100-200к одновременных ssl-запросов на обычных серверах (и
> ни в
> какой потолок не упираемся).
>
Надо около 600к-1000к постоянных коннекшенов держать и с клиентом и с пуш
серверами
миллион ? неплохо.
И это будет только расти. Ну и непонятное кол-во отваливающихся мобилок, с
которыми потом уже будем разбираться.
Возможно, что применим Гео ДНС для облегчения инициализации их SSL сессии и
лейтенси.
Зараз даже тяжело сказать сколько будет подсоединений. Их очень много и
видимо придется немного жертвовать мобилками и тьюнить беклоги и т.д.
изначально. Но если Вы думаете, что большой беклог изначально - безопасно,
то сразу и выставлю.
>
> > Хотим на днях запустить полноценный продакшен тест (а может и
> финальный
> > переход на nginx)
> >
> > Что еще можно подкрутить для уменьшения потребления памяти (если
> возможно
> > вообще)?
> >
>
> GeoIP память тратит :-)
для мобильноых абонентов, наверное, актуальна компрессия, там же каналы могут быть очень плохого качества. мы в тестах видели 25 мегабайт в секунду на одном ядре для дефолтного 6-го уровня сжатия. сервер с 24 ядрами может на лету жать 5 гигабит в секунду.
>
>
> > Может быть еще на что-то надо обратить внимание, без чего хорошего
> > перформанс не достигнуть?
> >
> > Понимаю, что чудес наверно ждать не стоит, но вдруг кто сталкивался
> с
> > чем-то
> > похожим и не спал ночами ;-)
> >
> > И еще вопрос многоуважаемым разработчикам:
> > Когда планируется (и планируется ли вообще) поддержка CyaSSL?
> > Промелькнуло пару постов, что вроде уже тесты идут, и по слухам
> потребление
> > памяти должно сильно упасть.
> > Я в траке искал, но может не там...ничего не нашел
> >
> > Спасибо!
> >
> > Posted at Nginx Forum:
> > http://forum.nginx.org/read.php?21,229967,229967#msg-229967
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru@xxxxxxxxx
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
Привожу конфиг под сервер с 64ГБ памяти.
с keepalive возможно перемудрил. Клиент висит и раз в 6 минут получает
keepalive я имел в виду на уровне http, не на tcp. у вас он включен, в предыдущем конфиге это было непонятно.
нолик, чтобы не отвалился, либо в любой момент получает пуш с данными от
байтов до сот килобайт
