Ужасные результаты Apache Bench на Custom CMS - PullRequest
Новая
       85

Ужасные результаты Apache Bench на Custom CMS

4 голосов
/ 28 сентября 2011

Обратите внимание: это не жалоба на некачественную CMS.

Просто играю с Apache Bench и получаю ужасные результаты с нашей собственной CMS, точнее я получил: 

Requests per second:    0.37 [#/sec] (mean)

Когда я запускаю другой тест с простым php-файлом, я получаю: 

Requests per second:    4786.07 [#/sec] (mean)

Еще один тест с предыдущей версией CMS: 

Requests per second:    6068.66 [#/sec] (mean)

Веб-сайт (s) работают нормально, проблем не обнаружено, Инструменты Google для веб-мастеров сообщают, что наши сайты работают быстрее, чем 80% страниц, и это нормально, я думаю.

Тест прошел: 

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

Может быть, какая-то проблема с Apache?Плохой .htaccess конфиг или что-то подобное?

Обновление:

Просто запустили простой тест с сокетами, и результаты были похожи.Страница загружается очень и очень медленно.Если я запускаю свой скрипт на другом веб-сайте, все в порядке.

Кроме того, есть небольшая подсказка о проблеме длины фрагмента.(Плохие заголовки Apache или окончания строк?)

Сайт взломан, и при включении подробного ведения журнала я вижу следующие строки в ответе: 

LOG: Response code = 200
LOG: header received:
HTTP/1.1 200 OK
Date: Tue, 04 Oct 2011 13:10:49 GMT
Server: Apache
Set-Cookie: PHPSESSID=ibnfoqir9fee2koirfl5mhm633; path=/
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2ef6

Всегда в одном месте, в середине HTML-источника, затем снова <!DOCTYPE HTML>.

Пожалуйста, помогите.

Обновление № 2:

Только что проверилмои HTTP-заголовки с помощью Rex Swain's HTTP Viewer и получили следующие результаты: 

HTTP/1.1·200·OK(CR)(LF)
Date:·Wed,·05·Oct·2011·08:33:51·GMT(CR)(LF)
Server:·Apache(CR)(LF)
Set-Cookie:·PHPSESSID=n88g3qcvv9p6irm1fo0qfse8m2;·path=/(CR)(LF)
Expires:·Sat,·26·Jul·1997·05:00:00·GMT(CR)(LF)
Cache-Control:·no-store,·no-cache,·must-revalidate(CR)(LF)
Pragma:·no-cache(CR)(LF)
Cache-Control:·post-check=0,·pre-check=0(CR)(LF)
Vary:·Accept-Encoding(CR)(LF)
Connection:·close(CR)(LF)
Transfer-Encoding:·chunked(CR)(LF)
Content-Type:·text/html;·charset=UTF-8(CR)(LF)
(CR)(LF)

Вы заметили что-нибудь необычное?

1 Ответ

4 голосов
/ 10 октября 2011

Если он хорошо работает с обычными веб-браузерами (как вы упомянули в комментариях), 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 не использует keep-alive, поэтому он ждет, когда придет ответ для закрытия сокета. Сервер закрывает его после 15 секунд простоя. Загрузка главной страницы с помощью wget также занимает 15 секунд. Wget также использует HTTP 1.0 в запросе.

Я думаю, что это ошибка в PHP-коде CMS, поскольку ab хорошо работает на том же сервере с простым php-файлом. В любом случае, вы можете обойти это, используя keep-alive соединения (-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), и клиенты с обычными браузерами этого не заметят.

...