?

Log in

No account? Create an account
Making PHP go faster: the Alternative PHP Cache - 'Twas brillig, and the slithy toves did gyre and gimble in the wabe [entries|archive|friends|userinfo]
Thomas

[ website | Beware the Jabberwock... ]
[ deviantArt | the-boggyb ]
[ FanFiction | Torkell ]
[ Tumblr | torkellr ]

Links
[Random links| BBC news | Vulture Central | Slashdot | Dangerous Prototypes | LWN | Raspberry Pi]
[Fellow blogs| a Half Empty Glass | the Broken Cube | The Music Jungle | Please remove your feet | A letter from home]
[Other haunts| Un4seen Developments | Jazz 2 Online | EmuTalk.net | Feng's shui]

Making PHP go faster: the Alternative PHP Cache [Monday 21st April 2014 at 6:59 pm]
Thomas

boggyb
[Tags|]
[Feeling |accomplishedaccomplished]
[Playing |Kumi Tanioka - When the Northern Sky Is Clear [Final Fantasy CC - Disc 2]]

Right, let's have another crack at that NAS.

Last time I'd come up with a hypothesis for why pleaseremove's HomePortal software was so slow on my NAS (namely, that PHP was spending most of its time just parsing the source files) and had attempted to prove this by installing the "official" Zend OPcache for PHP. Compiling it then failed because (as best as I can tell) it doesn't actually support the version of PHP on the NAS, despite what the documentation says. So let's have a go with something else...

Eeeny, meeny, miney, mo... that one! The Alternative PHP Cache.

As is par for the course there aren't any solid installation instructions on the website itself, merely a pointer to the PECL instructions which begin by "assuming a familiarity with the pear command" (which of course my NAS doesn't have). But the tarball does contain an INSTALL file with a sensible-looking set of commands, so let's give them a try.

Thomas@Athena:~/APC-3.1.13$ phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
Thomas@Athena:~/APC-3.1.13$ ./configure

...
configure: error: cannot guess build type; you must specify one

Sigh.

Thomas@Athena:~/APC-3.1.13$ wget "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD" -O config.guess
Thomas@Athena:~/APC-3.1.13$ wget "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD" -O config.sub
Thomas@Athena:~/APC-3.1.13$ ./configure
Thomas@Athena:~/APC-3.1.13$ make

...
In file included from /c/home/Thomas/APC-3.1.13/apc.c:43:
/c/home/Thomas/APC-3.1.13/apc_php_pcre.h:29:18: pcre.h: No such file or directory


"pcre" is probably the Perl-Compatible Regular Expression library. I would have thought the configure script would pick up on this, but nevermind. Let's see... it should be the libpcre3 and libpcre3-dev packages:

Thomas@Athena:~/APC-3.1.13$ sudo apt-get install libpcre3 libpcre3-dev
Thomas@Athena:~/APC-3.1.13$ ./configure
Thomas@Athena:~/APC-3.1.13$ make
Thomas@Athena:~/APC-3.1.13$ sudo make install
Installing shared extensions: /usr/lib/php5/20060613/
Installing header files: /usr/include/php5/
Thomas@Athena:~/APC-3.1.13$


Cool, that seems to have done something. Add extension = apc.so to /etc/php5/apache2/php.ini, restart the webserver with sudo /etc/init.d frontview restart, and APC now shows up in the phpinfo. There's far too many options that can be tweaked, but let's have a look and see if the defaults made any difference.

And it seems to have worked! Cumulative time is down from 4.262 seconds to just 2.205. Looking at the functions that were particularly slow before, most of them have improved dramatically:

FunctionTotal SelfTotal Self (with cache)Calls
load_class476ms96ms57
require::Smarty.class.php368ms28ms1
require_once::CodeIgniter.php340ms54ms1
DB306ms27ms1
CI_Loader->_ci_load_class163ms68ms8
CI_Loader->helper160ms43ms5
Smarty_Internal_TemplateBase->fetch148ms70ms5
php::mysql_query122ms128ms10
include_once::Mysmarty.php104ms12ms1

The notable exception is php::mysql_query, which is a database lookup and so won't be affected by the opcode cache at all.

So there we have it - my hypothesis was correct, and PHP was indeed spending a little under half the time just loading and parsing the PHP source files. There is still the question over where the rest of the performance has gone. Skimming through the profiler output nothing obvious jumps out as being responsible - the processing time seems equally split between My_Controller->__construct (887ms cumulative time) and Dashboard->index (937ms cumulative time). Any ideas, pleaseremove?
Link | Previous Entry | Share | Next Entry[ One penny | Penny for your thoughts? ]

Comments:
From: shozabred
Monday 21st April 2014 at 8:16 pm (UTC)
Try to write own one.
(Reply) (Thread)