Медленное подтверждение связи Apache при настройке prefork, требуется настройка конфигурации

Медленное подтверждение связи Apache при настройке prefork, требуется настройка конфигурации

На моем сервере, работающем под управлением 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 (например,МаксРеквестворкер) настройки. Сервер почти никогда не превышает среднюю нагрузку 1,5 или около того, и похоже, что памяти достаточно.

Может ли кто-нибудь подсказать, как мне сузить узкое место здесь и какие шаги я могу предпринять, чтобы это исправить? Любая помощь будет высоко оценена.

EDIT: Я посетил IRC-канал #apache и поспрашивал там, и дружелюбные ребята обратили мое внимание на тот факт, что этот сервер находится впрефоркmode и MinSpareServers, MaxSpareServers, StartServers и MaxRequestWorkers либо установлены по умолчанию, либо скорректированы, но все еще довольно низкие.

Они были совершенно непреклонны в том, что производственный сервер не должен использовать режим prefork, и дали мне несколько ссылок:

Я понимаю, что решение для исправления этих проблем с производительностью, вероятно, заключается в установке Apache для работы в режиме событий, но мой веб-сайт сложный и использует некоторые процессы разветвления и т. д. Я надеюсь, что в качестве временного решения, кто-то может предложить твики дляminSpareServers,maxSpareServers,startServers,maxRequestWorker

EDIT 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

решение1

Как оказалось, пакеты Ubuntu для установки Apache и PHP7 не предлагают ничего, кроме prefork, которыйдействительно отстой.В связи с этим мне пришлось обойтись 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.

Связанный контент