замедление как может быть связано с базой (например сессии сохраняются в базу, но не удаляются или еще какой-то мусор там складируется бесконечно), так может и не быть.
нередко у народа скрипты что-то запрашивают из внешних источников - вот вам замедляющий фактор, от которого ваш сайт будет рандомно больше/меньше тормозить.
ну или кто знает что там происходит, надо только смотреть...
сами sleep'ы ничего не замедлеют. как вам правильно сказали, скрипты открывают соединение, что-то делают с базой и потом болт забивают на закрытие. так оно и висит.
если мазолит глаза, добавьте в конфиг mysql например wait_timeout=1 и тогда mysql сама будет обрывать все соединения, которые секунду бездействуют.
но тогда логи начнут изобиловать сообщениями типа "[Warning] Aborted connection to db ..... (Got timeout reading communication packets)".
возможно количество sleep'ов это просто результат того что скрипты стали исполняться как говорите в 2-3 раза дольше. т.е. они и раньше были, но теперь просто больше стало т.к. больше времени проходит от запуска до завершения скрипта. возможно к базе подключается вначале, а закрывает соединение в конце. и вот эти несколько секунд коннект висит в статусе sleep.
в общем сперва надо решить проблему с медленным сайтом, а sleep'ы потом возможно сами и уйдут.
кто тут хотел сервер домой?
налетай:
https://www.avito.ru/sevastopol/nastolnye_kompyutery/e3-1265lv2_x9scm-f_32gb_ddr3_ecc_b.p._radiator_1963063686
около идеальный вариант. не совсем дно по мощности/скорости, при этом не сильно большой нагрев и энергопотребление. памяти много.
осталось вкинуть в картонную коробку и подвести пару провайдеров к нему :)
какой ответ вы тут хотите получить?
никто тут не видит что вы там видите.
можно было хоть дать ссылку на свой секретный сайт...
для начала узнайте время ожидания ответа.
в firefox нажать ctrl+i и дальше вот тут:
уж не знаю как в хроме, но тоже должно быть что-то подобное.
правильно сделанный сайт тут показывает цифру примерно равную пингу от вас к серверу.
если видим пол секунды и выше - все очень плохо.
что-либо еще советовать не видя пациента бессмысленно.
клиенту передано 251 - после 200 (ответ ОК)
а что в конце за цифры - намного эффективнее было бы спросить у них самих, а не тут.
почему многие так боятся поддержку хостинга, она для того и существует. и лучше них никто не ответит.
кэш. вся суть в кэшировании.
да, dnsmasq просто форвардит на те же 8.8.8.8 и 1.1.1.1, но при этом кэширует.
да, по времени там вроде разница мизер, но если помножить это на количество запросов, то получается уже заметно на глаз.
вот реальный пример. только что проверил:
видим что кэшированный запрос от локалхоста в 3 раза быстрее cloudflare и в 4 раза быстрее гугла.
ну это частный случай конкретно этого сервера. у других могут быть другие цифры.
днс сервера такие стоят:
т.е. первым локальный dnsmasq (который эту строку игнорирует при своей работе и обращается лишь к двум оставшимся)
и сейчас я делаю reload nginx'а с двумя сотнями сайтов за вот столько:
но как только в resolv.conf комментирую первую строчку с 127.0.0.1 и это же самое действие проходит уже за вот столько:
а когда подтупливали те внешние dns сервера все было еще сильно хуже и даже просто открывались https сайты с тормозами заметными на глаз.
стоило мне закомментировать ssl_stapling - все приходило в норму.
поставил dnsmasq - тоже порядок.
может я конечно чего не до конца понимаю, но факт в том что с тех пор как поставил кэширующий dnsmasq проблем больше не замечал. да и тот же reload (который нужен относительно часто когда добавляются/удаляются сайты) проходит почти незаметно. периодические ауты по несколько секунд никому не нужны. но и отключать ssl_stapling, теряя плюсы в ssllabs не охота.
возможно многие такие моменты не замечают т.к. проблема проявляется лишь при большом числе сайтов. если их там 3-5 шт. то конечно без разницы.
согласен, что это больше плацебо и ни на что особо не влияет, можно смело оставлять по-умолчанию. но вопрос же был про "оптимизацию". собственно вот она и есть. добавляем/правим фичи, понимая какие будут последствия, плюсы/минусы.
переход обратно с https на http обычно никому и не нужен, потому и говорю - да, ставим заголовок HSTS.
но просто мало ли, вдруг возникнет ситуация когда понадобится и чтоб не бегать по форумным гадалкам спрашивая почему не работает, надо осознавать как это работает и когда что-то может не работать.
даже если не установлен. можно отдельно собрать openssl 1.1 и собрать nginx, использующий именно этот openssl, а не системный.
хотя и в том что используется какая-то свежая ОС уже с openssl 1.1 тоже ничего необычного.
цель указана - оптимизация.
оптимизация это обычно означает какое-то улучшение или ускорение через убирание лишнего хлама.
но начинать надо с матчасти. понимать самостоятельно суть каждой настройки, а не просто копипастить что-то с форумов :)
по пунктам:
1) HSTS - да, но надо помнить о переходе обратном с https->http
да т.к. браузер в следующие заходы будет сразу обращаться куда надо, без лишнего обращения к http->редирект->https
2) tls 1.2 и 1.3 остальное отключено - да, но тоже надо помнить о древних клиентах.
3) ssl_stapling - да, но надо помнить о нюансе с dns и возможных тормозах из-за этого.
вот такие последовательности.
tls1.3 как nginx конфиге - AES256, потом CHACHA20
tls1.2 - как в openssl - AES128, AES256, CHACHA20
даже не спрашивайте почему так :)
довольно давно это настраивал. там все достаточно сложно замудрено.
но суть в том что надо во-первых требовать приоритета сервера и сервер чтоб в первым делом хотел один из AES'ов, лучше 128 т.к. он быстрей, а следующим CHACHA20 для недоклиентов.
весь остальной хлам просто отключаем.
уже не первый год включены лишь tls 1.2 и 1.3, остальное выключено.
крайне изредка кто-то под какой-нибудь winxp или ie древним замечает мол не открывается сайт и жалуется.
объясняю что да как. соглашаются что так пусть и остается.
пример сайта:
https://www.ssllabs.com/ssltest/analyze.html?d=vovk.com
ни одного "желтого", лишь кое-что красное из-за тех самых отключенных более старых протоколов.
все "зеленые полоски" можно довести до максимума, увеличив размеры ключей с 2048 до 4096
но это немного отразится на производительности. пока не помечает ssllabs желтым, пусть остается так.
Strict-Transport-Security тоже включен, но надо осознавать потенциальную проблему перехода обратно с https на http.
если к примеру вздумается и по http домен открыть, на который браузер уже заходил с таким заголовком, то ничего не получится. браузер будет упорно ломиться только на https сразу пока не наступит таймаут указанный в max-age
сбросить это можно, но не так просто как куки например.
по шифрам. у меня так:
ssl_prefer_server_ciphers on;ssl_ciphers 'ECDHE:+AES256:+CHACHA20:!AESCCM:!SHA384:!SHA256:!SHA:-3DES:!NULL:!RC4:!ARIA:!CAMELLIA';т.е. сообщаем о приоритете шифров сервера, а не клиента.
потом AES256 - как среднее между менее быстрым AES384 и более быстрым, но менее безопасным (или ssllabs его желтым отмечает, уж не помню) AES128.
CHACHA20 - для клиентов, чьи процессоры не имеют аппаратного AES.
остальное отключено (! знак)
помимо этого, nginx использует openssl, в которой тоже можно настроить шифры, протоколы и т.д.
у меня допустим так сделано:
в файле openssl.cnf добавлено:
[ssl_sect]system_default = system_default_sect[system_default_sect]MinProtocol = TLSv1.2Ciphersuites = TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256CipherString = ECDHE:+AES256:+CHACHA20:!AESCCM:!SHA384:!SHA256:!SHA:-3DES:!NULL:!RC4:!ARIA:!CAMELLIAOptions = ServerPreference,PrioritizeChaCha
т.е. тоже самое, протоколы только tls 1.2 и 1.3
те же шифры AES256 и CHACHA20, но еще доступен также AES128 (уж не вспомню так с ходу почему и зачем)
PrioritizeChaCha - там как-то хитро помнится... клиенты, которые могут AES, все равно будут AES256 использовать. а это лишь для тех кто не может.
это тоже включено у меня:
ssl_stapling on;ssl_stapling_verify on;но! не так давно из-за этого возникала одна проблема, которую не так просто было обнаружить.
суть вроде в том была, что при этом еще происходит обращение к dns серверам (из /etc/resolv.conf или там же в nginx конфиге resolver и resolver_timeout)
так вот однажды заметил что https сайты как-то тормознуто отвечают. начал ковырять, при перезагрузке nginx вообще страшно медленно это делал.
оказалось что по какой-то причине временно была плохая связь с гугловскими днс (8.8.8.8) или они сами по себе подтормаживали.
и при перезапуске nginx с парой сотен доменов с сертификатами и ssl_stapling'ом, происходило множество обращений к dns и отсюда тормоза.
в итоге решил дополнительной установкой локального кэширующего dnsmasq и указанием его как единственного в системе.
после чего nginx стал перегружаться моментом и все тормоза пропали.
вот такая история, о которой надо помнить, используя ssl_stapling
