Добрый день. Имею проблемы с виртуалкой на хостинге nic.ru ... их саппорт после суточных молчаний (все по регламенту) шлет отписки: "Выбранный Вами тарифный план является более профессиональным и подразумевает самостоятельное администрирование"... мы вам не поможем, у нас все хорошо...
Поэтому спрошу тут, может кто сталкивался с проблемой
Есть виртуалка и простенький сайт на ней (nginx, uwsgi, python/django, mariadb). Провожу нагрузочное тестирование с помощью Яндекс.Танк. По протоколу http (без ssl) сайт выдерживает приличные нагрузки -- 1000 запросов в секунду процессор поднимается максимум 1-2%... обстрел 10-20 тыс. запросов в секунду -- выдерживает при уровне процессора 30-40%.
Но при включении ssl (переход на https) уже при 30 запросах в секунду загрузка процессора 100%, при 45 запросах в секунду -- 10% ответов не может обработаться вообще (ошибки 5хх), а при 75 запросах -- не обрабатывается уже более половины запросов!
Что не так? Гугление показало, что обычно включение ssl дает всего 1-2% лишней загрузки процессоров (данные Amazon). Что не так с виртуалками nic.ru? Сервера у них старые, на Xeon E5-26xx. Но даже на этих старых процессорах есть набор AES-команд. Т.е. не должно быть такой разницы в нагрузке при обработке ssl. Что не так? Где узкое место? У меня, в настройках внутри виртуалки? Настройках гипервизора/виртуализатора у хостера? Наличие, например у хостера, резака трафика по http (от DOS-атак), а внутрь https они не могут лезть и потому виртуалка принимает весь трафик целиком???
UPD1: На всякий случай немного деталей:
В err-логах (когда ssl-включен и падает по нагрузке):
... [error] 15380#15380: *1576 connect() to ... ... ххх.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: ...
Соответственно ошибка 502... uwsgi по логам отрабатывает все штатно, никаких ошибок, все (HTTP/1.1 200)
В конфигах nginx при включении ssl добавляется (помимо 301-редиректа по 80-порту):
# ...
# ...
listen 443 ssl;
# ...
# ...
ssl_certificate /..xxx/xxx.crt;
ssl_certificate_key /..xxx/xxx.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_trusted_certificate /..xxx/xxx.crt;
resolver 77.88.8.8;
# ...
# ...
# ...
UPD2: Посмотрел внимательнее на лог uwsgi. Когда падает там вот такое:
[pid: 27377|app: 0|req: 12199/12199] xxx.xxx.xxx.xxx () {32 vars in 429 bytes} [Thu May 12 17:16:26 2022] GET /xxx => generated 0 bytes in 12 msecs (HTTP/1.1 200) 7 headers in 0 bytes (0 switches on core 0)
Thu May 12 17:16:27 2022 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request / (ip xxx.xxx.xxx.xxx) !!!
Thu May 12 17:16:27 2022 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 306] during GET / (xxx.xxx.xxx.xxx)
OSError: write error
P.S. думаю, что саппорт любого хостера будет отвечать в том же духе про свои виртуалки... Хотя если кто-то знает более дружелюбный хостинг и саппорт --советуйте.
Простой
Простой
