бенчмаркинг — очень медленное выполнение php-скриптов на сервере

Этот вопрос связан с моим другим вопросом, нашел здесь.

Сначала я подумал, что это проблема с сетью, но все более вероятно, что это как-то связано с моей конфигурацией php и работой php-файлов. Я сделал следующие тестовые случаи:

Я создал файл php, назвал его test.phpсо следующим содержанием:

 <?php
echo 'test';
?>

и создал два bash-файла со следующим содержимым:

//bash1.sh
#!/bin/bash
/usr/bin/php /testFirstByte/test.php

а другой с

//bash2.sh
#!/bin/bash
echo Test;

Затем я начал отсчитывать время их запуска, выполняя каждый и предшествуя ему командой time, т.е. time php test.php

Результаты приведены ниже:

 // time php test.php
test
real    0m0.548s
user    0m0.445s
sys     0m0.101s

 

 // time sh bash2.hs
Test
real    0m0.002s
user    0m0.002s
sys     0m0.000s

 

 // time sh bash1.hs
X-Powered-By: PHP/5.5.30
Content-type: text/html; charset=utf-8
test
real    0m0.539s
user    0m0.429s
sys     0m0.108s

Для меня это выглядит так, что всякий раз, когда я пытаюсь запустить скрипт PHP, время выполнения увеличивается как минимум на полсекунды, независимо от того, какой скрипт php я пытаюсь запустить. Я не могу понять, как решить эту проблему, поэтому любая помощь будет очень признательна!

РЕДАКТИРОВАТЬ 1: Я сделал простой скрипт, надеюсь, именно это вы и имели в виду под внутренним тестом @Eineki. Сценарий выглядит следующим образом:

$timer = microtime(true);
require('test_simple.php');
$end = microtime(true) - $timer;
echo "Require test duration was: " . $end . " seconds\n";

$timer = microtime(true);
exec('php test_simple.php');
$end = microtime(true) - $timer;
echo "Exec test duration was: " . $end . " seconds\n";

Результаты были следующими:

Требуемая продолжительность теста составила: 0,00102400779724 секунд.
Длительность теста Exec составила: 0,61318397522 секунд.

РЕДАКТИРОВАТЬ 2: список загруженных расширений выглядит следующим образом:

Array
(
[0] => Core
[1] => date
[2] => ereg
[3] => libxml
[4] => openssl
[5] => pcre
[6] => sqlite3
[7] => zlib
[8] => bcmath
[9] => bz2
[10] => calendar
[11] => ctype
[12] => curl
[13] => dom
[14] => hash
[15] => fileinfo
[16] => filter
[17] => ftp
[18] => gd
[19] => gettext
[20] => SPL
[21] => iconv
[22] => session
[23] => json
[24] => mbstring
[25] => mcrypt
[26] => standard
[27] => mysql
[28] => mysqli
[29] => mysqlnd
[30] => Phar
[31] => posix
[32] => Reflection
[33] => imap
[34] => SimpleXML
[35] => sockets
[36] => exif
[37] => tokenizer
[38] => xml
[39] => xmlreader
[40] => xmlwriter
[41] => zip
[42] => cgi-fcgi
[43] => PDO
[44] => pdo_sqlite
[45] => pdo_mysql
[46] => mailparse
[47] => Zend OPcache
)

И это моя версия PHP, по состоянию на php -v:

PHP 5.5.30 (cgi-fcgi) (built: Dec  3 2015 06:55:27)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend    Technologies

РЕДАКТИРОВАТЬ 3: Запустить strace как предложено @voter в файле php, как на рабочем сервере (рассматриваемый сервер), так и на нашем сервере разработки, где эта проблема не возникает. Все что strace выходных данных в основном в 10 раз больше на сервере prod, чем на сервере dev. Может быть, кто-то знаком с strace можно из этого сделать вывод?

РЕДАКТИРОВАТЬ 4:

Исключение из vmstat 1 команда:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
5  0 3163644 5410932 2522564 13417292    0    1    22    62    1    0 18  6 75  1  0
2  0 3163644 5845884 2522568 13406468    0    0     0   916 31787 5966  9  6 85  0  0
8  0 3163644 5439468 2522572 13406840    0    0     8   432 50513 5322 12  6 82  0  0
4  0 3163644 5750124 2522572 13407624    0    0     4   232 54417 5615  8  7 86  0  0
4  0 3163644 5748608 2522576 13407480    0    0     4   760 118206 5736  7  9 83  0  0
3  0 3163644 5742648 2522576 13418040    0    0     0   244 68462 6689 10  7 83  0  0
4  0 3163644 5671104 2522576 13407620    0    0    40   568 34157 4222  7  5 87  0  0
4  0 3163644 5980828 2522580 13401712    0    0    16   524 43754 6391 17  6 77  0  0
5  0 3163644 5506988 2522592 13418868    0    0   264   280 59452 5955 16  7 77  0  0
5  0 3163644 5577116 2522600 13417800    0    0    32   540 68056 8968 11  6 83  0  0
7  0 3163644 4747580 2522612 13451468    0    0    16   376 241800 7107 12 13 75  0  0
4  0 3163644 4948548 2522616 13440832    0    0    12   468 354599 5155  7 16 77  0  0

РЕДАКТИРОВАТЬ 5:

Результаты top команда на сервере:

top - 09:17:58 up 15 days,  1:53,  8 users,  load average: 6.90, 6.22, 5.34
Tasks: 687 total,   3 running, 683 sleeping,   0 stopped,   1 zombie
Cpu(s): 15.0%us,  3.4%sy,  0.0%ni, 80.7%id,  0.8%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  49390000k total, 43364688k used,  6025312k free,  2697344k buffers
Swap: 16482300k total,  3495772k used, 12986528k free, 11878096k cached

4

Решение

Ваш php -v вывод выглядит так, как будто вы вызываете php cgi из командной строки.

Для командной строки обычно есть версия php для CLI, которую можно установить отдельно, например, apt-get install php5-cli,

Это может оказать довольно большое влияние на производительность. Быстрый тест на сервере Linux среднего размера дает мне

#time php-cgi test.php
X-Powered-By: PHP/5.5.26
Content-type: text/html

test
real    0m0.117s
user    0m0.036s
sys     0m0.076s

# time php test.php
test
real    0m0.074s
user    0m0.040s
sys     0m0.036s

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

Это, вероятно, не поможет вам с вопросом в другой теме, которую вы упомянули, если вы не используете там модуль CGI и не настроили его правильно.

3

Другие решения

Наконец, выяснил, что является причиной проблемы: это было одно из расширений, а именно, browsecap продление или, скорее, его отсутствие.

В какой-то момент он был установлен, но когда мы поняли, что не будем его использовать, по разным причинам мы его удалили, но он не был удален из php.ini файл. Удаляя одну строку, связанную с browsecap из файла ini проблема решена полностью.

Я хотел бы поблагодарить @Pampy за то, что он указал мне правильное направление с расширениями. Если в будущем кто-нибудь столкнется с чем-то схожим, вариант отладки, если проблема схожая, — запустить php из командной строки с помощью команды -n параметр, который фактически отключает его ini, и все загруженные расширения одновременно.

2

для меня это работает нормально.

/usr/bin/php -q script.php > /dev/null &

попробуйте, я хотел бы увидеть результаты вашей конфигурации. Так как он запускается из командной строки, я подозреваю, что вам не нужен вывод. Вы можете отправить входные данные в качестве аргументов.

0
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector