Hello!

On Tue, Sep 03, 2019 at 03:18:36PM +0500, Dmitry Sergeev wrote:

> Добрый день,  спасибо за ответ.
> 
> On 02/09/2019 22:11, Maxim Dounin wrote:
> > Just in case, для работы такая конфигурация смысла не имеет - если
> > тикеты выключены, то ключ для их шифрования не нужен.  Ключ имеет
> > смысл задавать, если тикеты включены.
> >
> > С точки зрения влияния на reload - внешний ключ позволит сохранить
> > тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш
> > сессий.
> >
> > Ну выключать тикеты - это, безусловно, плохой путь.  Тикеты -
> > способ переложить хранение сессий на клиентов, и отказываться от
> > этого - очевидно недальновидно с точки зрения нагрузки на сервер.
> >
> Да, я неверно понял доки.
> 
> > Отмечу также, что даже в наиболее экстремальных случаях из
> > представленных на графике - рост потребления процессора с ~200% до
> > ~300% не выглядит сколько-нибудь фатальным.  Какой-то рост
> > потребления процессора при релоадах - нормален, здесь же
> > наблюдается рост всего в 1.5 раза.  Если это проблема - то стоит
> > задуматься о добавлении мощностей и/или заняться оптимизацией
> Да, сейчас это для меня просто представляет интерес, после перехода на 
> openssl 1.0.2g и включение http2, проблем это особых не вызывает.
> > А вот то, что средняя нагрузка без тикетов заметно выше - это
> > немного странно.  Само хранение сессий - должно бы стоить очень
> > недорого с точки зрения процессора, а в остальном разница не
> > принципиальна.  Но, возможно, тут дело в том, что размер кэша
> > SSL-сессий просто мал для имеющегося количества клиентов, и
> > поэтому при выключении тикетов handshake'и начинают происходить
> > чаще, что и приводит к росту потребления процессора.
> Возможно. Это немного не то, но мне было интересно как увеличение кэша 
> ssl сессий повлияет на нагрузку при reload'e:
> 
> http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg
> 
> Числами отметил разное количество ssl_session_cache от 20m до 256m. 
> Вроде никак не влияет.  Сегодня тестил при 8K rps (вчера 5-6K). Поэтому 
> нагрузка скачет чуть выше.

От размера кэша сессий должна зависеть высота "полки" между 
reload'ами.  Если кэш мал - то полных handshake'ов будет больше, 
чем могло бы быть, и соответственно CPU usage в полке будет 
больше.  Ну и всё это имеет смысл скорее при выключенных тикетах, 
о чём и шла речь выше.  А на графике - они, похоже, включены.

> А вот тикеты помогли вообще круто.  Нагрузка поднимается всего-лишь на 
> 5%-10%:
> http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg
> 
> Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными 
> тикетами и указанными постояным ключем ssl_session_ticket_key.

Ну ок, то есть как и ожидалось - пик явно из-за SSL handshake'ов, 
использование постоянных ключей для тикетов - лечит.

> Итого:
> 
> Сущесвтенно решить проблему помогло следующее:
> 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и 
> при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а 
> раньше от 30-40 секунд, до 5 минут).
> 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло 
> включение ssl_session_tickets(по умолчанию включено) с установелнным 
> ssl_session_ticket_key (по умолчанию генерируется заново при каждом 
> reload'e, его лучше указать чтобы этого не происходило).
> 
> Оставил такие параметры:
> 
>      ssl_session_cache   shared:SSL:20m;
>      ssl_session_timeout 30m;
>      ssl_session_tickets on;
>      ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - 
> файл с рандомными 80 или 48 байт
> 
> Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет 
> (по крайней мере я этого не заметил).

Использовать "ssl_session_tickets on;" - не нужно, это поведение 
по умолчанию.  И отмечу также, что ключ для тикетов - надо 
периодически менять, ибо получив этот ключ - можно расшифровать 
весь трафик.

И я бы ещё рекомендовал посмотреть в сторону ECDSA-сертификатов, 
там handshake банально на порядок быстрее при той же 
криптостойкости:

$ openssl speed rsa2048 ecdsap256
...
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000992s 0.000033s   1008.1  30297.9
                              sign    verify    sign/s verify/s
 256 bit ecdsa (nistp256)   0.0001s   0.0001s  17145.0   9276.9

То есть 1008.1 подписей в секунду в случае RSA 2048 bit, и 17145.0 
подписей в секунду для ECDSA 256 bit.

-- 
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Ответить