Very slow execution of php scripts on the server

Question

This question is related to my other question, found here.

At first I tought that this is a networking problem, but it seems more and more likely, that this has something to do with my php configuration, and the running of the php files. I've made the following test cases:

I've created a php file, named it test.php, with the following content:

 <?php
 echo 'test';
 ?>

and created two bash files, with the following contents:

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

and the other with

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

Then I proceeded to time their run, running each and preceeding it with the 'time' command, ie: time php test.php

The results are as follows:

 // 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

For me it looks like, that whenever I try to run a PHP script, the runtime is increased with at least half a second, for whichever php script I try to run. I can't figure out how to resolve this issue, so any help would be greatly appreaciated!

EDIT 1: I've made a simple script, I hope this is what you meant by the inside test @Eineki. The script is as follows:

$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";

The results were as follows:

Require test duration was: 0.00102400779724 seconds
Exec test duration was: 0.61318397522 seconds

EDIT 2: the list of loaded extensions are as follows:

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
)

And this is my php version, as of 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

EDIT 3: Run an strace as suggested by @voter on the php file, both on the production server (the server in question), and on our development server, where this problem does not occur. Everything that strace outputs is basically 10 times more on the prod server, then on the dev server. Maybe someone familiar with strace can gather a conclusion from this?

EDIT 4:

Exceprt from vmstat 1 command:

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 

EDIT 5:

The results of a top command on the server:

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

Your php -v output looks like you're calling php cgi from the command line.

For the command line, there's usually a CLI version of php, which can be installed separately, e.g. apt-get install php5-cli.

This can have a quite big impact on performance. A quick test on a medium-sizes linux server gives me

#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

As you can see, the time for the cgi version is doubled. Can you try with the CLI version instead to see if the difference is still that big?

That probably won't help you with the question in the other thread you mentioned, unless you're also using the CGI module there and didn't configure it correctly.

Answer 2

Finally found what was causing the issue: it was one of the extensions, namely, the browsecap extension, or more likely, the lack of it.

At some point, it was installed, but when we realized, we wouldn't use it, for different kind of reasons, we uninstalled it, yet it wasn't removed from the php.ini file. By removing a single line related to browsecap from the ini file, the problem solved completly.

I would like to thank @Pampy for pointing me in the right direction, with the extensions. If anyone experiences something simmilar in the future, an option to debug if the problem is simmilar, is to run php from the command line, with the -n parameter, which actually disables it's ini, and all the loaded extensions at once.