Re: nginx SSL offload в highload проекте

["ShivaS" <nginx-forum@xxxxxxxx>]

Илья, огромное спасибо за то, что так подробно ответили и проявили интерес!
Запуск намечаем на сегодня ;-)
Ну а теперь подробнее, и в самом конце приведу свой полный конфиг

Илья Шипицин Wrote:
-------------------------------------------------------
> 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, это Вы имели в виду?
Остальное я ничего не выбирал...ну или не совсем понимаю вопроса.

> 
> у ECDHE минус в том, что он пока не очень поддерживается на стороне
> клиента. но не в производительности.
> 
> 

Я еще читал про патч от Гугла который это дело разгоняет нехило, ЕСС, но
вроде там какие-то траблы с лицензией, только в определенных страннах
использовать и т.д.. 
Я в принципе пока и не рискую этим пользоваться, потестировал, посмотрел,
память съелась ну и решил сделать идентично с ELB
Основная проблема в этих вечно отваливающихся клиентах и ELB таймаутах.
Таймауты то решиться должны вроде, а вот с отваливанием клиентов посмотрим,
когда будет продакшен. iDevices и Андроиды работают без этого сервиса,
напрямую TCP. А вот для всех остальных терминация сервиса идет по https,
возможно не везде я что-то правильно выбрал и не все девайсы индо-китая
могут поддержать то, что я им навязываю. Ну и BB и Win7 phone тоже сюда,
хотя они четко работают и не отваливаются.

> 
> > Может, там что-то и подкручено, но меня интересует в основном
> потребление
> > памяти, а разницы с 1.0 в тестах не заметил
> >
> > Кеш выставил, но шансы что клиент переподсоединиться на тот же
> сервер -
> > минимальны, но сотню мегов не жалко ;-)
> >
> 
> ssl_session_cache  ?
> в приведенном конфиге ее нет.
> покажите полный конфиг ?
> 

Да, укажу его в самом конце.

> >
> > ну и sysctl соответственно тоже.
> >
> > Сейчас вот подумываем очень серьезно о полном переходе на nginx в
> качестве
> > основного оффлоадера.
> >
> 
> какая у вас нагрузка ?
> мы держим 100-200к одновременных ssl-запросов на обычных серверах (и
> ни в
> какой потолок не упираемся).
> 

Надо около 600к-1000к постоянных коннекшенов держать и с клиентом и с пуш
серверами
И это будет только расти. Ну и непонятное кол-во отваливающихся мобилок, с
которыми потом уже будем разбираться.
Возможно, что применим Гео ДНС для облегчения инициализации их SSL сессии и
лейтенси.
Зараз даже тяжело сказать сколько будет подсоединений. Их очень много и
видимо придется немного жертвовать мобилками и тьюнить беклоги и т.д.
изначально. Но если Вы думаете, что большой беклог изначально - безопасно,
то сразу и выставлю.

> 
> > Хотим на днях запустить полноценный продакшен тест (а может и
> финальный
> > переход на nginx)
> >
> > Что еще можно подкрутить для уменьшения потребления памяти (если
> возможно
> > вообще)?
> >
> 
> GeoIP память тратит :-)

геоайпи нема, только оффлоад и пуш на бекенде.

> покажите nginx -V

nginx version: nginx/1.2.3
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx
--with-http_ssl_module --with-http_realip_module --without-http_gzip_module
--without-http_fastcgi_module --without-http_empty_gif_module
--http-log-path=/var/log/nginx --with-http_stub_status_module
--without-http_ssi_module --without-http_geo_module
--without-http_split_clients_module --without-http_uwsgi_module
--without-http_scgi_module --without-http_memcached_module
--without-http_charset_module --without-http_auth_basic_module
--without-http_autoindex_module --without-http_referer_module
--without-http_limit_conn_module --without-http_limit_req_module
--without-http-cache --without-mail_pop3_module --without-mail_imap_module
--without-mail_smtp_module --without-pcre --without-http_rewrite_module

> 
> 
> > Может быть еще на что-то надо обратить внимание, без чего хорошего
> > перформанс не достигнуть?
> >
> > Понимаю, что чудес наверно ждать не стоит, но вдруг кто сталкивался
> с
> > чем-то
> > похожим и не спал ночами ;-)
> >
> > И еще вопрос многоуважаемым разработчикам:
> > Когда планируется (и планируется ли вообще) поддержка 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 минут получает
нолик, чтобы не отвалился, либо в любой момент получает пуш с данными от
байтов до сот килобайт

nginx.conf:

worker_processes  8;
worker_rlimit_nofile 409600;
worker_priority -5;

events  {
        worker_connections  50000;
        use epoll;
        multi_accept on;
  accept_mutex on;
        }

#GLOBAL SETTINGS
http {


log_format main      '$remote_addr - $host - $hostname - $http_name -
$document_uri - $request_uri - $server_protocol - $server_name - $uri -
$remote_user [$time_local] '
                         '"$request" $status $bytes_sent '
                         '"$http_referer" "$http_user_agent" ' ;


    server_tokens       off;

    error_log /usr/local/nginx/logs/error_log debug;
    access_log off;
    #access_log /var/log/nginx/access_log main;

    default_type  application/octet-stream;

    client_header_timeout  10m;
    client_body_timeout    10m;
    send_timeout           10m;

    client_header_buffer_size    1k;
    large_client_header_buffers  4 4k;

    output_buffers   1 32k;
    postpone_output  1460;

    sendfile         on;
    tcp_nopush       on;
    tcp_nodelay      on;

keepalive_timeout     600;

keepalive_requests 1000000;


upstream push {
ip_hash;

keepalive 60000;

server 1.1.1.1;
<<ну тут список из многих бекенд пуш серверов>>


}

include       mime.types;
include       site.conf;
}

В теперь конфиг сайта самого


################
# HTTPS server #
################

    server {
        listen       *:443 default backlog=4096 so_keepalive=30m::10;
        server_name  имя;

        access_log   off;
        #access_log /var/log/nginx/access_ssl_log main;
        error_log    /var/log/nginx/error_ssl_log debug;

        ssl                  on;
        ssl_certificate     
/usr/local/nginx/conf/ssl/conf/ssl/cert.com.pem;
        ssl_certificate_key 
/usr/local/nginx/conf/ssl/conf/ssl/cert.com.key;

        ssl_session_cache    shared:SSL:100m;

        ssl_session_timeout  10m;

       ssl_protocols TLSv1;
       ssl_prefer_server_ciphers   on;
       ssl_ciphers AES256-SHA:HIGH:!aNULL:!MD5;



        client_max_body_size 0M;
        client_body_buffer_size    128k;
        client_body_temp_path      /var/tmp;

        proxy_connect_timeout      75;
        proxy_send_timeout         600;
        send_timeout               600;
        proxy_read_timeout         600;

        proxy_buffer_size          4k;
        proxy_buffers              4 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 64k;

        proxy_temp_path            /tmp;

  location / {
      proxy_pass http://push;
      proxy_http_version 1.1;
      proxy_set_header Connection "";
      proxy_buffering off;
    }

   }


И добавки в sysctl.conf

net.core.somaxconn = 3240000
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.core.rmem_default = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_orphans = 300000
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_keepalive_intvl = 600
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_syn_backlog = 3240000
net.ipv4.ip_local_port_range = 2000   65000
net.ipv4.tcp_wmem = 4096      65536   16777216
net.ipv4.tcp_rmem = 4096      87380   16777216


вот что-то около того

Спасибо!

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,229967,230015#msg-230015

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru