На моем сервере, работающем под управлением 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 MPM- описывает режим событий Apache
- Запуск PHP на Apache httpd- список опций для запуска php на apache
- Рассказ об openssl_seal(), PHP и Apache2handle- описание эксплойтов на php, о которых следует знать
Я понимаю, что решение для исправления этих проблем с производительностью, вероятно, заключается в установке 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.