Missing APC

[hal]

Hi there, Hawkhost!

I have noticed that APC is not installed on the venus server. Is this intentional?

Running my PHP Framework on a PHP accelerator, preferably APC, is highly recommended by the developers.

APC does seem to be compatible, and I imagine it would reduce the resources being consumed overall on the server.

http://www.litespeedtech.com/how-tos.html#qa_phpacc

Would you consider installing it?

Thank you in advance

Hal

[Brian]

Hal,

APC does not play nicely with Zend Optimizer which is in far more demand than APC.

[hal]

OK, Brian, that is understandable.

However, there are other php accelerators available. Would you consider using one of those? Particularly, anecdotal opinion across the web suggests that eAccelerator works well with Zend Optimizer:

http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html

http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html

http://blog.taragana.com/index.php/archive/php-performance-with-eaccelerator-versus-eaccelerator-with-php-zend-optimizer/

http://www.webhostingtalk.com/archive/index.php/t-595594.html

http://www.debian-administration.org/articles/574#comment_2

To be clear, the Zend Optimizer that is currently installed allows scripts encoded by Zend Guard Loader to be run, doesn't it? Why is this important? I have read that although Optimizer does indeed optimize code, the method it uses provides negligible benefit in some situations.

http://www.webhostingtalk.com/archive/index.php/t-595594.html

"ZO does some reasonable optimisations and will generally speed up execution. However, and here's the rub, when you add in the time taken to optimise code, whether there is an overall net gain in performance is far from certain, and it's not uncommon to get a slow down when ZO is installed. Last time we looked, this wasn't helped from time being spent optimising code that might not even be executed because ZO didn't perform lazy optimisation."

Thanks

Hal

[Tony]

Customers purchase zend encoded scripts which we have to support. It's the same reason we also run ioncube as a lot of commercial PHP scripts are encoded.

As far as eaccelerator or any opcode cacher we have no interest in using any of them at this time. They are great when you're running a single site or control the sites but when you do not it's a headache. With the single site I'd test each one and make sure it all works. They're not suppose to be buggy but they are so some scripts don't work properly or in certain code situations PHP crashes. For us when we're trying to support thousands of users we'd rather take the CPU hit then deal with the support headache of certain scripts not working.

[hal]

Tony

A PHP accelerator/opcode cache is a prerequisite to running symfony, my chosen framework. Symfony is used to run a number of high-traffic sites, each coping with millions of users. For example,

http://www.symfony-project.org/blog/category/Case+studies

I have not heard of an incompatibility or problem with applications or plugins running on symfony, not least because symfony encourages good coding practices and APC is extensively tested in production environments.

eAccelerator is a good alternative, providing equivlent performance benefits to APC, and being equally well-tested and mature.

If certain scripts experience difficulties running with these caching engines then that could well be caused by bad coding in the script. For instance, it is often the case that autoloaders that people write load classes in a different order when using an accelerator compared with not using one. The Symfony autoloader, and I guess the Zend one too, does not experience any such problem, because it was written with a good knowledge of the underlying architecture.

While frameworks are great for standardising common coding tasks which would otherwise be difficult for an individual developer to get right, and also encouraging best practices and efficient code design, their weakness is their large codebase, which take time to execute on each request. The same can be said for other software, like CMSes such as Joomla for example which I have been running recently and noticed that the administrator interface runs painfully slow on the Hawkhost server I am using. Using an opcode cache typically increase the performance considerably of these apps because the code is already precompiled and ready to run.

Hal

[Tony]

No PHP code requires op code caching. That includes frameworks and and popular PHP scrips. Here's how PHP works

PHP loads -> Parses Source -> Compiles -> Executes

Here's what the op code cachers do:

PHP Loads -> Checks mtime -> Checks compiled source memory -> Checks compiled source file system -> Executes

So what it does is avoids the parsing and compiling of the PHP code. It's attempting to remove middleman steps.

It works really well when you have a single pool of PHP processes on top of control of your applications. We have neither of those as we run PHP as the user and we are relying on other users.

Here's how our system works:

HTTP Request -> PHP Request -> Checks PHP Processes for User -> If None Create One -> Execute PHP using Process Avaiable

So for an OP code cacher to even work we're talking about having memory pools per user because there is no shared memory among different user processes. Also PHP processes die off so if there are no visitors for a while the user has no processes in the pool. So that case they have no shared memory available at all. The only thing it can do is file system caching but that's not really where the performance gains are. The gains are from common PHP code being in memory already so no reading in files.

As far as an administrative area of a script being the only one to run slow that makes no sense. The PHP parsing and compiling source does not suddenly become slower for certain pages. It's far more likely something is running within the PHP script to cause it to do whatever it's doing.

So basically what I am saying is for our environment it makes no sense to run these. If we were running mod_php or one PHP process as one user it probably would. But we do not along with the majority of hosts because running PHP as the user nobody adds all kinds of security problems. For example upload folders need to be 777 (anyone can read, write and execute) and once the files are there they cannot be removed by the user.

What we do to increase performance is using LSAPI PHP which is a pool of PHP processes. Most hosts running PHP as the user are using suPHP which is doing CGI which means loading PHP itself every time. We do not do that s long as the user is getting enough requests in where it makes sense to have pools on stand by. If it's one request every 10 minutes it makes no sense but one every 30 seconds it provides significant gains. The only way a host could do this with Apache is running FastCGI with one of the other special FastCGI modules but they'd be in our situation with op code cachers being pretty much useless and probably hurting performance.

[hal]

Tony

I can see now why an opcode cache is not suitable for this kind of environment.

Thank you for a very informed and informative explanation.

Hal