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
