To cache or not to cache and how to cache

[jair101]

Here is the story. My website is small to medium sized - about 10k pageviews per day, 1800 uniques, up to 100 users online in peaktime including bots. Currently I am on a shared hosting, but I am moving to VPS soon, which is 1GB Ram+1GB vSwap and 2 CPU cores.

I am setuping this VPS with Webmin/Virtualmin as panel, because I am not expirienced enough to administer it on my own. Now, this panel supports 3 types of PHP execution:

mod_php - which I read is old, memory hog, unsafe, and generally not recommended

cgi - safer, but still inefficient

fcgid - recommended out of the three.

Here comes the caching problem. Apparently both APC and Xcache does not support opcode cache with multiple php processes and this is the way fcgid works. I've read a lot about the issue, but still wonder which is the best course of action considering my website and the specs of the VPS:

1. run mod_php + APC/Xcache. I still don't know what is the problem with this setup, but people all over the internet are saying to not use mod_php.

1.1. Maybe run nginx to handle static files, thus helping the memory heavy mod_php?

2. run fcgid + APC/Xcache and try to limit the number of processes, thus risking crashes. But if I set the number of processes too high, then the caching will be inefficient (each process has its own cache) and there will be more memory wasted. I don't even know if my server has enough RAM to handle the separate cache of each process

3. run fcgid and use only user caching with APC/Xcache. This will be a shame as I read that opcode cache is highly recommended.

4. Scratch everything and go nginx+php-fpm. Problem is that I have 0 expirience and will rely mostly on Kirito's post here. I don't think Virtualmin has solid nginx support either.

What would you recommend for my situation? My community is growing steadily, so I am trying to think a little bit in advance.

[stoo2000]

Here is the story. My website is small to medium sized - about 10k pageviews per day, 1800 uniques, up to 100 users online in peaktime including bots. Currently I am on a shared hosting, but I am moving to VPS soon, which is 1GB Ram+1GB vSwap and 2 CPU cores.

I am setuping this VPS with Webmin/Virtualmin as panel, because I am not expirienced enough to administer it on my own. Now, this panel supports 3 types of PHP execution:

mod_php - which I read is old, memory hog, unsafe, and generally not recommended

cgi - safer, but still inefficient

fcgid - recommended out of the three.

Here comes the caching problem. Apparently both APC and Xcache does not support opcode cache with multiple php processes and this is the way fcgid works. I've read a lot about the issue, but still wonder which is the best course of action considering my website and the specs of the VPS:

1. run mod_php + APC/Xcache. I still don't know what is the problem with this setup, but people all over the internet are saying to not use mod_php.

1.1. Maybe run nginx to handle static files, thus helping the memory heavy mod_php?

2. run fcgid + APC/Xcache and try to limit the number of processes, thus risking crashes. But if I set the number of processes too high, then the caching will be inefficient (each process has its own cache) and there will be more memory wasted. I don't even know if my server has enough RAM to handle the separate cache of each process

3. run fcgid and use only user caching with APC/Xcache. This will be a shame as I read that opcode cache is highly recommended.

4. Scratch everything and go nginx+php-fpm. Problem is that I have 0 expirience and will rely mostly on Kirito's post here. I don't think Virtualmin has solid nginx support either.

What would you recommend for my situation? My community is growing steadily, so I am trying to think a little bit in advance.

You might want to evaluate Centmin Mod- http://centminmod.com/

It was setup on a VPS that one of my clients use, the result was a very quick IP.Board. (IPContent Index page generation is 0.05/0.06 seconds)

[Aiwa]

http://www.invisionpower.com/support/guides/_/advanced-and-developers/api-methods/kernel-caching-libraries-classcachephp-r153

[jair101]

You might want to evaluate Centmin Mod- http://centminmod.com/

It was setup on a VPS that one of my clients use, the result was a very quick IP.Board. (IPContent Index page generation is 0.05/0.06 seconds)

Thanks, I already setup my VPS with Ubuntu, but I can reinstall it as a last resort.

http://www.invisionpower.com/support/guides/_/advanced-and-developers/api-methods/kernel-caching-libraries-classcachephp-r153

Thanks Aiwa, but I think this relates to user cache and my main issue is with how to run opcode cache together with fcgid. Should I disable the opcode cache or run it very ineffectively with fcgid or use mod_php and lose the advantages of fcgid. Thats basically my problem.

[Grumpy]

mod_php isn't so bad that it's something you can't use... In fact, I think it's pretty decent. If others can't tell you why mod_php is bad, they probably don't know and just regurgitating what they heard. And it's more likely that they have a problem with how apache handles mod_php rather than mod_php itself.

Yes, mod_php is the oldest, that is, it was the first to be made. So new that they didn't even put its name in the module name. mod_php basically means php as a module, but one it's running is DSO. DSO still gets updates though, so, even though it may be old, it's not like you're running an old code.

DSO is the fastest php handler for apache. fcgi is... despite its name, not as fast as dso. I frankly haven't seen any benchmarks where fcgi beats dso in pure php handling/second if not resource constrained. It's called fast because it's faster than cgi due to how configurations are loaded in cgi (cgi will load everything every time). cgi sucks... so, no need to even really consider that.

The security concern of using dso is suEXE, that is, running php under each user rather than under "nobody" which dso will use. That requires "other" permission mask which creates the risk. But as you are running your server just for yourself, so this is not a factor. You have no security concern of using dso over fcgi/cgi.

Now we come to main discussion of why dso may be bad. Resources. But, as I said, it's not because dso is bad, but it's because apache is bad. Apache always loads dso if installed. Doesn't matter what you asked for, it's going to load it. You wanted a jpg file? Better load dso. So, this always loading of a module that's not necessary causes a lot of bloat and is a significant amount. apache will load fcgi module too, but it's a much lighter weight and will only pass it on to the php handler when it actually needs to be handled (this is why it's cgi). This is largely similar principle as nginx+php-fpm.

But... it's not really that php-fpm is so much superior to dso/fcgi, but that nginx is so much superior than apache as a web server. So you end up saving huge amounts of resources. apache really sucks at being a web server these days... Just aren't keeping up with the competition and bloat issues.

You shouldn't have any problems using opcache with fcgi actually. It will consume more memory than dso for apc. But we're not talking about unreasonable amounts. It will cost many multiples in memory... but chances are, you'll probably use less than 50MB under dso. So, even some multiple of this shouldn't be something unmanageable. It's important to distinguish guides and recommendations against usage of fcgi+opcache for shared hosting providers vs yourself (one site, one server). For shared hosting providers, fcgi+opcache is not practical because you need to have separate cache for each users. This comes out to huge amounts of memory wasted for sites that rarely get any visit. So the model of overselling becomes unpractical. But for a single site running fcgi, opcache memory usage isn't something outlandish.

If you are really considering not using opcache b/c of fcgi, I suggest you just run dso + opcache instead.

[jair101]

Thanks Grumpy, very detailed and clear. It comes to this though:

It will cost many multiples in memory... but chances are, you'll probably use less than 50MB under dso. So, even some multiple of this shouldn't be something unmanageable.

How many multiples of this? I see recommendations to leave max processes at around 5-10. So with 10 processes it is close to 500mb of ram, which is half of what my VPS has. It sounds like in this case DSO will be leaner overall.

By the way, I have two more sites there, but they are insignificant, I don't plan to enable opcode cache on them at all.

[IveLeft...]

Grumpy - What do you think of Unixy Varnish out of interest ?

[handsoffsam]

Varnish isn't a real good fit for IPB, given that just about every page is unique for each visitor. It is much more interesting in situations where you're serving the same resources for many people.

robert

[Grumpy]

Grumpy - What do you think of Unixy Varnish out of interest ?

I lack the knowledge/experience to comment in depth for varnish (or unixy package). But in principle, I don't find it a good fit for IPB. As handsoffsam mentioned above, it's core focus is an aspect that can't be served very well for a forum which displays different for every user and even guests. That's not to say varnish's rest of the features are terrible, but I'd assume their page caching is their main focus and thus gathers the most attention and refinement. As nginx and varnish do actually carry each others features - the important ones at least. So I haven't seen the need to explore varnish very much.

Compared to apache, I'm sure it's awesome...

[Grumpy]

Thanks Grumpy, very detailed and clear. It comes to this though:

How many multiples of this? I see recommendations to leave max processes at around 5-10. So with 10 processes it is close to 500mb of ram, which is half of what my VPS has. It sounds like in this case DSO will be leaner overall.

By the way, I have two more sites there, but they are insignificant, I don't plan to enable opcode cache on them at all.

I can't say... but you could just try it out and see if the caches hold stably.

Your cgi's max process need not be very high. If it's out of processes, apache is just queue it for you and serve when ready (given it's not beyond timeout). You can try having something like 5 static fcgi processes. I don't think it's a direct multiplicative factor, but if it were, then it'd be 250mb; something you can afford.

Also, I'll just note... it's best to pretend your vswap doesn't exist when planning these (which I think you are). It's probably so terrible that if it ever enters swap, you'd think your site crashed. Not that vps swaps are terrible, but swaps in general are terrible for webservers unless your host did something amazing (i doubt it) or on ssd (still not amazing).