Мой сервер под управлением Ubuntu 14 / Apache2.4.7 имеет перенаправление htaccess, чтобы заставить все запросы использовать HTTPS. Как правило, он быстро реагирует. Однако недавно я изменил свою конфигурацию SSL, чтобы ограничить используемые шифры более современными настройками, чтобы предотвратить heartbleed, beast и другие эксплойты и обеспечить использование современных методов шифрования.
В последнее время я получил несколько жалоб - которые, похоже, не связаны с этими изменениями (см. Ниже) - что моя машина временами может работать медленно. Эти жалобы предполагают, что это может быть связано с рукопожатием или установлением соединения:
У меня периодически возникала медленная загрузка страниц с различными сообщениями о состоянии браузера в зависимости от используемого браузера; все это связано с ожиданием установления безопасного соединения.
Я написал PHP-скрипт, который тысячу раз использует cURL для подключения. Я запустил его вчера поздно вечером, и медлительность, похоже, не была проблемой. Я попытался подключиться к https, а также к http, выполнив указанное выше перенаправление. Все запросы выполняются за 3,5 секунды или меньше, при этом подавляющее большинство (96–98%) выполняется менее чем за 1,5 секунды.
Я запустил тот же сценарий в 10:30 сегодня утром по калифорнийскому времени, и около 10% запросов заняли больше 1,5 секунды, а многие - намного больше. Самое долгое время было около 17 секунд.
Мои исследования и интуиция подсказывают мне, что, хотя квитирование https сложнее, чем HTTP-соединения, эту проблему, вероятно, можно решить, настроив мою конфигурацию apache (например, MaxRequestWorker) настройки. Сервер почти никогда не превышает средней нагрузки 1,5 или около того, и похоже, что памяти достаточно.
Может ли кто-нибудь подсказать, как я могу сузить узкое место здесь и какие шаги я могу предпринять, чтобы исправить это? Любая помощь приветствуется.
РЕДАКТИРОВАТЬ: Я посетил канал IRC #apache и спросил там, и дружелюбные люди обратили мое внимание на тот факт, что этот сервер находится в Prefork mode и MinSpareServers, MaxSpareServers, StartServers и MaxRequestWorkers либо по умолчанию, либо настроены, но все еще довольно низкие.
Они были непреклонны в том, что производственный сервер не должен использовать режим предварительной вилки, и направили меня по нескольким ссылкам:
Насколько я понимаю, решением для исправления этих проблем с производительностью, вероятно, является установка apache для работы в режиме событий, но мой веб-сайт сложен и использует некоторые ветвления процессов и прочее. Я надеюсь, что в качестве временного решения некоторые могут предложить настройки minSpareServers, maxSpareServers, startServers, maxRequestWorker
РЕДАКТИРОВАТЬ 2: Разбор типичного медленного запроса, как сообщает curl_getinfo функция в PHP:
elapsed: 17.6722049713
ssl_verify_result: 0
total_time: 17.671187
namelookup_time: 0.000051
connect_time: 0.065855
pretransfer_time: 16.787012
starttransfer_time: 17.340403
redirect_time: 0.261569
Как оказалось, пакеты Ubuntu для установки apache и php7, похоже, не предлагают ничего, кроме prefork, который действительно отстой. В этом случае мне пришлось довольствоваться предварительным форком, который вообще не является идеальным решением, но до тех пор, пока у меня не будет дополнительной информации о том, как получить один из рекомендуемые конфигурации работает, это мой единственный вариант.
Отредактировал файл /etc/apache2/mods-available/mpm_prefork.conf:
sudo nano /etc/apache2/mods-available/mpm_prefork.conf
И увеличил параметр MaxRequestWorkers до 300. НОТА что для этого мне также нужно добавить параметр ServerLimit, равный 300, или MaxRequestWorkers ограничен значением по умолчанию ServerLimit, равным 256:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
# changed in response to slow connect/handshaking time complaints
ServerLimit 300
# note this value is constrained by ServerLimit, which defaults to 256
MaxRequestWorkers 300
MaxConnectionsPerChild 0
Эти настройки, похоже, снизили медлительность. Я использовал свой тестовый сценарий PHP в загруженное время дня, и все запросы выполнялись за 3,5 секунды или меньше, подавляющее большинство из которых выполнялось менее чем за 1,5 секунды. Я также тестировал apache bench и высокое значение параллелизма, и я мог видеть, как сервер отвечает, порождая рабочих, но у меня все еще было много свободной оперативной памяти:
ab -n 1000 -c 100 "https://example.com/"
Я проверил оперативную память:
free -h
Похоже, что сейчас это работает, хотя крайне разочаровывает то, что я не могу заставить apache использовать fastCGI с помощью установщиков ubuntu.