Apache and PHP with fcgi on 10.04

[Jordon Bedwell]

On 08/08/11 16:54, Wipe_Out wrote:
> Jordon.. Have got it working.. Thanks for the input.. Going to start tuning it 
> to my needs now..

No problem. I'm here to help.

> I understand that for each virtual server a new php process will be created and 
> will remain until the time out or the number of requests has been filled..

Yes, this is correct, read below for more info on that.

> Will more than one php process ever be created for a single virtual server? If 
> so how is this controlled?

Well it's a complicated algorithm IMO when it comes to optimising
processes. Theoretically for such a small server slightly more spawns
(some people and yes one client did take this quite literally and called
me and hour later saying he spawned 100 children and raced his server,
he got mad when I laughed at him on the phone, I found that quite
funny), you also want less requests so you can that you collect better
but for a rapid server where things are constantly evolving in traffic,
spawning causes latency which you don't want at all. Overhead is
overhead is OVERHEAD is THIS SYSADMIN SUCKS FIRE HIM on a busy server.
So you start adjusting requests and then after a determined amount of
requests you start to spawn more children and lowering requests and
adjusting based on what you experience in most latent times.  Right now
I would suggest you up children spawns to 5 and lower requests to
n<100-300 so it starts collecting faster.  If you see processes that sit
around all day then lower your spawns first and increment your requests
per child on a need be basis.

To clarify my horrible run on English:
If Children is defaulted to 3:
Small Server == Slightly more children w/ less requests
Medium Server == Slightly more children with slightly more requests
Large Server == High requests per child, children adjusted by analysis.

So by that:
Small Server == 3 - 7 children with 100-300 requests per.
Medium Server == 3 - 11 children with 300-1300 requests per.
Large Server == Switch to FPM with 1300 to n-optimised requests per.
^ To clarify Large, you'll still need to optimise startup children too.
Past large server I won't explain, that will just complicate things.

You can get into a lot more trouble with FPM, believe me on that, even
though it's meant to make management easier, it's easiness can destroy
some sysadmins who do not pay attention and just leave it as it is, talk
about some overhead.  With normal FCGI you have to pay attention or it's
game over, with FPM it's only game over after the goalie takes a
football to the eye and gets knocked out. I've seen guys who are
spawning so many children at once with FPM their server just gives up
and calls it, hits the shower.  It's not even gonna play this game,
forfeit. So you have to think about that when you start building your
server, and a lot of people who manage their own servers don't think
about that at all until they have that WTF MY SERVER IS DEAD moment.

---

If you want dynamic children you'll need to uninstall php5-cgi and
install php5-fpm (which Ubuntu and Debian now both include because it's
now apart of PHP since 5.3 if I remember right, could be a revision off)

> If I wanted to use APC I would I need to restrict the number of processes for a 
> virtual server to 1 so that it doesn't chew up all the server memory with a 
> separate cache per process?

No the APC cache is shared.

> I have a virtual server with only 512MB ram hosting a couple of drupal sites so 
> APC would be useful but I need to make sure the fcgi processes don't saturate 
> the memory..

Well, since I don't know the stats of your server I can't say for sure
if it would be harmful or helpful.  At this point based on the specs
you've given me I can assume it would be harmful because the server
already lacks the visitors to justify constant caching, but then again
one could argue that caching would speed up requests when there are very
few requests, but I could come back with there being an abundant amount
of resources available so it would be a waste of memory that could be
used for oh snap moments.  I can argue with myself over this all day,
don't dare me to.

---

A lot of what I said is based on work experience but every server is
different so I tried to highlight that you need to analyse things on a
per server and client basis and not go off a general algorithm because
every case is very different.  The algorithm only defines the base set
of rules, you need to adjust the algorithm on your own.