Fcgi and cache (xcache-APC eAccellerator)

[ASTRAPI]

Hello

When i use the fcgi option on APache handler i got wrong stats with xcache :(

When a user registers the first minute was ok the stats down on the left on my forum.

Then after a few minutes new users was registered and after i press F5 to refresh the page every time i got wrong stats.

Some times 550 (correct stat) after F5 again i got 546 and again 542 and then 550 and every time i was refreshing the page i got thisproblem and the same also happend with the shoutbox and topic replies.

I was reply and then after f5 reply was there and then F5 again and the reply gone and after a whie f5 and the reply is back.

Then i go back to DSO Apache Handler and all problems gone.

Can anyone confirm that any of those cache systems work great using fcgi please?

Give me some more info please.

Thank you

[ASTRAPI]

The xcache author told me:

the current looks you have is: httpd as fcgi manager, managing many

php-fcgi workers(childs). it not only make your stats wrong but also

take up a lot of memory, because each php-fcgi worker allocate its own

XCache cache memory

the target result should be: _1_ php-fcgi parent, with many php-fcgi

workers(childs)

the key is, php as a fcgi manager should be the parent of worker childs

But how i can do this?

[Luke]

I haven't personally experienced this issue mainly because I've been using Apache + mod_fcgid + PHP without an opcode cache engine. But I have been doing a lot of reading on the subject mainly because our company is trying to make our application more scalable by making use of things like memory data caching. I'm pretty sure I have a grasp on the subject now, but if I am at all wrong someone please correct me.

A opcode cache engine will not work well with php-fcgi. The reason for this is because you have a parent fast cgi parent process and controlling dedicated php processes as children. The result is each php "child" (really a parent php process) has it's own separate cache. When you set a cache value in one process the others do not have access to the same space. Typically with a php-fcgi setup a php process has a limited life span and handles only so many requests before it is killed and another is created. This limits the ability for data to persist.

The php-fcgi sapi has the ability to spawn it's own sub-process (actual children). The "recommendation" (which is out of date) is to configure fast cgi to only create a single php process and configure PHP to create it's own children. You would also want the parent php process to have a long lasting life to be effective. This "solves" the problem, but keeping the parent php process around is not reliable. Also it means you cannot use mod_fcgid (newer than mod_fastcgi) because it can only pass one request at a time to it's spawned children (which was reduced to one). This means that it is "blocking". The only way around this is to use the older mod_fastcgi.

The biggest issue is the php-fcgi just doesn't manage child processes very well. There is a new sapi called php-fpm (fast cgi process manager). This exists as a patch for 5.2, and is built into 5.3.3. If you really wanted to use Apache I you should be able to use it with mod_proxy_fcgi, but I personally have no experience with it.

If you have a choice the real question is do you even want to use Apache still. Apache is tried and tested, but it's old and consumes a lot of resources. The better alternative as I've come to know is Nginx. In many benchmarks I've seen it does double the requests per second than Apache (static requests) and scales very well. It's also a lot easier to configure. The only downside is no .htaccess, but if you read this page http://wiki.nginx.or...Apache-htaccess you can understand why. The best part is you shouldn't have any of these issues.