![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
torkellRight, let's have another crack at that NAS.
Last time I'd come up with a hypothesis for why![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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:
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?
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:
| Function | Total Self | Total Self (with cache) | Calls |
|---|---|---|---|
| load_class | 476ms | 96ms | 57 |
| require::Smarty.class.php | 368ms | 28ms | 1 |
| require_once::CodeIgniter.php | 340ms | 54ms | 1 |
| DB | 306ms | 27ms | 1 |
| CI_Loader->_ci_load_class | 163ms | 68ms | 8 |
| CI_Loader->helper | 160ms | 43ms | 5 |
| Smarty_Internal_TemplateBase->fetch | 148ms | 70ms | 5 |
| php::mysql_query | 122ms | 128ms | 10 |
| include_once::Mysmarty.php | 104ms | 12ms | 1 |
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?
