PHP запускает тест Drupal медленнее, чем должно быть

Question

Первоначально я разместил это на ServerFault ... но, возможно, это больше вопрос языка PHP.

У меня есть сервер с Dual Xeon Quad Core L5420, работающий на частоте 2,5 ГГц,Я оптимизировал свой сервер и пришел к моему последнему узкому месту: PHP.

Мой очень простой PHP-скрипт:

. / Test.php

<?php print_r(posix_getpwuid(posix_getuid()));

Мой не столь научный, потому что они не обращают внимания на блокировку потока, но "достаточно научны, чтобы дать мне разумный многопоточный запрос в секунду"сценарии:

. / benchmark-php

#!/bin/bash
if [ -z $1 ]; then
  LIMIT=10
else
  LIMIT=$1
fi

if [ -z $2 ]; then
  SCRIPT="index.php"
else
  SCRIPT=$2
fi

START=$(date +%s.%N)
COUNT=0
while (( $COUNT < $LIMIT ))
do
  php $SCRIPT > /dev/null
  COUNT=$(echo "$COUNT + 1" | bc)
done
END=$(date +%s.%N)
DIFF=$(echo "$END - $START" | bc)
REQS_PER_SEC=$(echo "scale=2; $COUNT / $DIFF" | bc)
echo $REQS_PER_SEC

. / действительно-benchmark-php

#!/bin/bash
if [ -z $1 ]; then
  LIMIT=10
else
  LIMIT=$1
fi

if [ -z $2 ]; then
  THREADS=16
else
  THREADS=$2
fi

if [ -z $3 ]; then
  SCRIPT="index.php"
else
  SCRIPT=$3
fi

PIDS=""

echo '' > results
for thread in `seq 1 $THREADS`; do
  ./benchmark-php $LIMIT $SCRIPT >> results &
  PIDS="$PIDS $!"
done

for PID in $PIDS; do
  wait $PID
done

RESULTS=`cat results`
MATH="0"
for RESULT in $RESULTS; do
  MATH="$MATH + $RESULT"
done

echo "$MATH" | bc

Результат выполнения ./really-benchmark-php 100 8 test.php составляет ~ 137 запросов всекунда.

Выполнение одного и того же сценария на экземпляре Drupal с поддержкой sqlite или mysql возвращает ~ 1,5 req / s.

У меня установлены APC и mem_cache, и я убедился, что ониработает по умолчанию.(Да, APC enable_cli также включен.) Кто-нибудь знает магический переключатель «заставить PHP выполняться быстрее»?

У меня есть альтернативная конфигурация конфигурации (FPM / FastCGI), которая обслуживает ~ 140 запросов / сУстановка MySQL Drupal ... как это могло быть возможно, если сам PHP не может даже обслуживать 2 запроса в секунду из командной строки?

Результат инструмента ab кажется мне таким же низким:

статическая страница: ab -n 1000 -c 100 http://x.x.x.x/ запросов в секунду: 683,71

тест php: ab -n 100 -c 5 http://x.x.x.x/ запросов в секунду: 41,38

drupal-mysql: ab -n 100 -c 10 http://x.x.x.x/drupal/ запросов в секунду:0,24

drupal-sqlite: ab -n 100 -c 10 http://x.x.x.x/drupal-test/ Количество запросов в секунду: 4,92

Answer 1

Drupal Core (неоптимизированный, не кэшированный, без APC, ужасен для производительности / просмотров страниц в секунду).

Короче говоря.Используйте Varnish или какой-либо другой кеш обратного прокси.

В целом, впечатляет.Мне удалось увеличить процент запросов страниц, которые я мог обработать, на 167407,84% в процентах.

Start: 0.51
End : 854.29

Вот разница в производительности и

Вот некоторые соответствующие фрагменты из моего поста.это показывает разные цифры.

Тест 1 (получить начальный тест)

Запустить тест Apache

ab -k -n 100 -c 100 -g step1.txt http://example.com/how-it-works

Хорошо, поэтому этот запрос полностью убил мой сервер.Смотрите график ниже.

Итак, я решил уменьшить количество запросов, чтобы просто определить стандартные запросы в секунду.Я отправил 100 запросов с уровнем параллелизма 2.

И вот что получилось:

Concurrency Level:      2
Time taken for tests:   197.855 seconds
Complete requests:      100
Requests per second: 0.51 [#/sec] (mean)
Time per request: 3957.105 [ms] (mean)

Тест 2 APC включен

Затем я повторил тест, но с включенным APC.

Concurrency Level:      2
Time taken for tests:   87.270 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      2138900 bytes
HTML transferred:       2096300 bytes
Requests per second:    1.15 [#/sec] (mean)
Time per request:       1745.396 [ms] (mean)
Time per request:       872.698 [ms] (mean, across all concurrent requests)

Как видите, это заметно лучше.Но все же ужасно .1 запрос в секунду !?лол.Это ужасно.

Тест 3 - Включить кеширование Drupal Core

Затем я включил кеширование Drupal Core ... и повторил тест Apache

ab -k -n 100 -c 5 -g test2-c5-k.txt http://example.com/how-it-works

Concurrency Level:      2
Time taken for tests:   23.229 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      1923002 bytes
HTML transferred:       1880900 bytes
Requests per second:    4.30 [#/sec] (mean)
Time per request:       464.580 [ms] (mean)
Time per request:       232.290 [ms] (mean, across all concurrent requests)
Transfer rate:          80.84 [Kbytes/sec] received

Так что теперь у меня получилось 4 запроса в секунду.Что значительно лучше, но все же, как правило, отстой.

Последний шаг, добавление приложения обратного прокси-кеша в смесь.Что я хочу увидеть? .. Мне на самом деле все равно, что должно быть лучше, чем 4 запроса в секунду.Если я смогу получить около 300 запросов в секунду, то я буду рад.Все, что близко к 1000 запросам, я буду в восторге.

Вот чем я закончил:

Concurrency Level:      300
Time taken for tests:   11.706 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    10000
Total transferred:      190260000 bytes
HTML transferred:       185140000 bytes
Requests per second:    854.29 [#/sec] (mean)
Time per request:       351.168 [ms] (mean)

В целом, довольно впечатляюще.Мне удалось увеличить процент запросов страниц в секунду на 167407,84% .

Start: 0.51
End : 854.29

И дополнительно я сократил время загрузки страницы на запрос с 1978 мс до 1,17 мс(одновременно), что является общим увеличением скорости ... много .Скорость снижается на 99,94%.Ой