在服务器上执行 php 脚本非常慢

Question

这个问题与我的另一个问题found here有关。

起初我认为这是一个网络问题，但似乎越来越有可能，这与我的 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 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 秒
执行测试持续时间为：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： 按照@voter 的建议在 php 文件上运行 strace，在生产服务器（有问题的服务器）和我们的开发服务器上运行此问题所在的位置不会发生。 strace 输出的所有内容在 prod 服务器上基本上是 10 倍，然后是在 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

Answer 1

您的php -v 输出看起来像您正在从命令行调用 php cgi。

对于命令行，通常有一个 CLI 版本的 php，可以单独安装，例如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 模块并且没有正确配置它。

Answer 2

终于找到了导致问题的原因：它是扩展之一，即browsecap 扩展，或者更有可能是缺少它。

在某个时候，它已安装，但当我们意识到我们不会使用它时，出于各种原因，我们将其卸载，但它并未从 php.ini 文件中删除。通过从ini文件中删除与browsecap相关的一行，问题就彻底解决了。

我要感谢 @Pampy 为我指明了正确的方向，以及扩展。如果将来有人遇到类似的事情，如果问题是类似的，调试的一个选项是从命令行运行 php，使用 -n 参数，这实际上禁用了它的 ini，以及一次加载的所有扩展。

Answer 3

对我来说这很好用。

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

试一试，我想看看你的配置结果。由于它是命令行触发的，我怀疑您不需要输出。您可以将输入作为参数发送。