Ужасные результаты Apache Bench на пользовательской CMS

Если он хорошо работает с обычными веб-браузерами (как вы упомянули в комментариях), CMS по-разному обрабатывает запросы от Apache Benchmark.

Краткий контрольный список:

• AFAIK Apache Benchmark просто отправляет простые запросы без обработки файлов cookie, поэтому попробуйте установить -C с действительным файлом cookie (скопируйте значения из веб-браузера).
• Попробуйте отправить в CMS точно такие же заголовки, какие отправляет веб-браузер. Сохраните дамп действительного запроса с помощью netcat, HttpFox или анализатора пакетов и установите отсутствующие заголовки с помощью -H.
• Профилируйте CMS на сервере, пока вы отправляете на него запрос с помощью Apache Benchmark. Возможно, вы нашли узкое место. Два вызова бедняги error_log с меткой времени в первой и последней строке index.php (или точки входа тестируемого скрипта) может показать, насколько быстр PHP-скрипт, и помочь рассчитать накладные расходы HTTP-сервера Apache и сети.
• Если вы запускаете тесты сокетов и тесты браузера с разных компьютеров, это может быть проблема с DNS (отключите HostnameLookups в Apache). Попробуйте запустить их с одной машины.
• Попробуйте ab -k ... или ab -H "Connection: close" ....

Я предполагаю, что CMS выполняет некоторую дорогостоящую инициализацию, когда она инициализирует сеанс, и это происходит, когда она обрабатывает первый запрос. Поскольку Apache Benchmark не отправляет файлы cookie обратно в CMS, он создает новый сеанс для каждого запроса, и это является причиной медленных ответов.

Второе предположение заключается в том, что CMS обрабатывает входящие заголовки http по-разному, а заголовки, которые были отправлены (или их отсутствие) Apache Benchmark, вызывают некоторую дорогостоящую/медленную обработку. Это выглядит более уместно после отчета Google Webmaster Tools.

Apache Benchmark отправляет запрос HTTP 1.0, например:

GET / HTTP/1.0
Host: localhost:9100
User-Agent: ApacheBench/2.3
Accept: */*

Мне кажется, что ваш сервер не отправляет HTTP-заголовок о настройках Keep-Alive, но предполагает, что клиент использует keep-alive, когда клиент использует HTTP 1.0. Это не соответствует RFC-совместимому поведению:

Из RFC 2616, 19.6.2 Совместимость с постоянными подключениями HTTP/1.0:

Некоторым клиентам и серверам может потребоваться совместимость с некоторыми
предыдущими реализациями постоянных соединений в клиентах и ​​серверах HTTP/1.0
. Постоянные подключения в HTTP/1.0
оговариваются явно, поскольку они не являются поведением по умолчанию.

По умолчанию Apache Benchmark не использует поддержку активности, поэтому он ждет, когда придет ответ для закрытия сокета. Сервер закрывает его после 15 секунд простоя. Загрузка главной страницы с помощью wget также занимает 15 секунд. Wget также использует HTTP 1.0 в запросе.

Я думаю, что это ошибка в коде PHP CMS, поскольку ab хорошо работает на том же сервере с простым файлом php. В любом случае, вы можете обойти это, используя поддерживающие соединения (-k):

ab -k -t 30 -c 10 http://example.com/

или с явным отключением постоянных соединений:

ab -H "Connection: close" -t 30 -c 10 http://example.com/

но это все еще проблема на стороне сервера, и ваши исходные команды ab верны.

Обратите внимание, что эта ошибка, вероятно, затрагивает только клиентов HTTP 1.0 (например, Apache Benchmark, wget), и клиенты с обычными браузерами ее не заметят.