PHP opcode Cache that work with suPHP?

N

nmb

Verified User
Joined
Sep 13, 2008
Messages
191
Hi,


I have a question if there is any PHP opcode cache that really work with suPHP? I've used suPHP before and found that my server was always overloaded. (load average is more than 20 most of the time.)

Then, I decided to try PHP CLI, it worked a bit better. (load is about 14 - 18) Then, right after I've installed xCache. My load went below 2 which is normal for a Quad CPU.

I, then, switched back to PHP CGI but now with xCache installed. That didn't help at all. My load went back to more than 20 again. So, I had to switch back to PHP CLI again.

Today, I found that xCache doesn't work with suPHP. I also saw an article somewhere said eAccelerator doesn't work with suPHP either. Another article about APC + suPHP said that it cache some of PHP code but very less.

Any idea?


Thanks,
________
Vaporizer wiki
 
Last edited:
you must install fcgi which currently is not supported by directadmin.
 
I would like to add that the reason any opcode cacher (APC, XCache, eAccelerator etc.) won't work with suPHP or direct CGI is because opcode caching works only on persistent PHP instances: the opcode (result of the interpretation of a PHP script) is cached in (shared, between threads and childs) memory and if PHP is killed and restarted for any page... well, there is no advantage at all, it is even worst.

The PHP module for Apache creates a persistent instance, as does FastCGI.
Those are the only ways I known about, and since mod_php does not allow separated, setuid/setgid instances by user (unless using one of the many experimental modules for Apache that do that) I guess FastCGI is the only secured way to allow opcode caching on shared production systems.
 
Last edited:
tillo said:
I would like to add that the reason any opcode cacher (APC, XCache, eAccelerator etc.) won't work with suPHP or direct CGI is because opcode caching works only on persistent PHP instances: the opcode (result of the interpretation of a PHP script) is cached in (shared, between threads and childs) memory and if PHP is killed and restarted for any page... well, there is no advantage at all, it is even worst.

The PHP module for Apache creates a persistent instance, as does FastCGI.
Those are the only ways I known about, and since mod_php does not allow separated, setuid/setgid instances by user (unless using one of the many experimental modules for Apache that do that) I guess FastCGI is the only secured way to allow opcode caching on shared production systems.
Click to expand...

I saw one of your posts that you are getting 500 errors does that still happends to your website? And have you seen a significant improvement on the performance of your system after doing your setup?
 
I am not having 500 errors since I have been using APC instead of XCache, but this may not apply to everyone: I have uncommon PHP software running.

The improvement I experienced is outstanding (server was stalling for minutes, with up to 200 CPU+IO load, because of certain PHP compilations and now it's almost idle), but again this may not apply to everyone: if you have many low traffic websites opcode caching is not the solution, unless you have massive amount of memory (to store ALL of the opcode) or, instead, you select caching only for the most visited websites.
 
Thanks tillo Ill try to follow your tutorial and see what happends :)
 
tillo, before all - thank yoou for your tutorial. Before I start make changes ona my vps i have a question: it is possible to switch fastcgi + apc mode for only one domain, and others work on standard mode cgi/suphp? Because i have about 30 webpages but only two of them needs speed-kick ;-).

On vps i have 384MB RAM / 768 swap and i worry about if all webpages uses fastcgi there will be not enough memory for all.

Is it possible and - if yes - how to do this?
 
Last edited:
You can run two separate versions of PHP (for example, 4.x and 5.x) and run one as fastcgi, and one as httpd module. You can not run different or the same minor versions that way, though.

Hopefully someone else can tell you how; I don't remember the details and I don't have time to look it up.

Jeff
 
You must log in or register to reply here.
Back
Top