| Trying to make PHP go faster |
[Saturday 22nd February 2014 at 9:59 pm]
Thomas
|
| [ | Tags | | | nas adventures | ] |
| [ | Feeling |
| |  disappointed | ] |
| [ | Playing |
| | Hell's Heaven ~ Enigma/Seven Lives Many Faces | ] |
Right, so last time I'd successfully installed a profiler and produced an output file. Let's take a look...
Sorting the output by "Total Self" (which is the total amount of time spent executing that particular function, not counting time in subfunctions) the biggest consumers are:
| Function | Total Self | Calls |
|---|
| load_class | 476ms | 57 |
| require::Smarty.class.php | 368ms | 1 |
| require_once::CodeIgniter.php | 340ms | 1 |
| DB | 306ms | 1 |
| CI_Loader->_ci_load_class | 163ms | 8 |
| CI_Loader->helper | 160ms | 5 |
| Smarty_Internal_TemplateBase->fetch | 148ms | 5 |
| php::mysql_query | 122ms | 10 |
| include_once::Mysmarty.php | 104ms | 1 |
That lot is fully half the 4.262 seconds it took to load Craig's HomePortal dashboard, and of that 639ms is spent in classloading and 812ms in include/require functions. Oh, and the PHP files loaded by those functions don't look particularly complex (Mysmarty.php contains an if !defined('basepath'), a require, and a class definition) so I don't think it's doing much real work in that time. This does still suggest that a fair chunk of time is spent just parsing PHP code.
The next step is probably to add a PHP parser/opcode cache and see if that helps. I'm going to pick the Zend OPcache for no particular reason. Unfortunately their website has no documentation whatsoever, but fortunately the tarball does include a README with destructions. So, here goes...
Thomas@Athena:~/zendopcache-7.0.3$ phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
Thomas@Athena:~/zendopcache-7.0.3$ ./configure
Lots of tests...
checking build system type... ./config.guess: unable to guess system type
Well, I know what to do with that at least. It'd be useful if all these autoconf-users updated to something vaguely current (configure claims it was last modified in 2005!).
Thomas@Athena:~/zendopcache-7.0.3$ wget "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD" -O config.guess
Thomas@Athena:~/zendopcache-7.0.3$ wget "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD" -O config.sub
Thomas@Athena:~/zendopcache-7.0.3$ ./configure
Lots of pointless tests (why is it checking for a Fortran compiler anyway?)...
Thomas@Athena:~/zendopcache-7.0.3$ make
...
zendopcache-7.0.3/zend_accelerator_util_funcs.c: In function `zend_clone_zval':
zendopcache-7.0.3/zend_accelerator_util_funcs.c:236: error: `zend_uintptr_t' undeclared (first use in this function)
Well that didn't take long to fail. Some searching throws up this bug for a different PHP extension which exactly matches what's happening here. Which would suggest that the latest Zend OPcache hasn't actually been tested with PHP 5.2 (despite claiming to support that version). Anyway... I added typedef unsigned long zend_uintptr_t; to /usr/include/php5/Zend/zend_types.h and tried again:
zendopcache-7.0.3/Optimizer/zend_optimizer.c: In function `zend_optimizer':
zendopcache-7.0.3/Optimizer/zend_optimizer.c:310: error: `ZEND_ACC_INTERACTIVE' undeclared (first use in this function)
Unfortunately there's almost nothing online relating to this error, and a quick grep through the headers in /usr/include/php5 didn't throw it up either. My PHP-fu isn't anywhere near strong enough to start digging into the internals so I've given up at this point. I have at least raised a bug about the compiler errors, so let's see where that goes... |
|
