I'll look into it. Thanks for the recommendation.

Now that I've had a chance to remove a lot of the bloat left over while on shared hosting, the forum is performing very well.

I'm still looking to scrap apache altogether and replace it with nginx + php-fqm + memcache + apc. The tests so far have exceeded all expectations.

Here is my test set up:

Nginx - No Cache (Still looking for a solution)
PHP-fqm - APC
Vbulletin - Memcache

Wouldn't mind having squid or varnish in front to handle all non cached static requests.

Just glad it wasn't the lower hosting packages being overloaded. I've been a fan of linode and set up for a while now and am pleased with the results.

Don't bother sticking anything in front of nginx. Nginx is perfectly capable of handling static requests _very_ efficiently.

I'll test out both scenarios. I assume the following would be optimal:

Varnish --(Static)-> Nginx
Nginx --(Dynamic)-> php-fpm(apc)
Vbulletin -> Memcache

A static request coming in should be handled directly by Nginx.
A dynamic request would be proxied by Nginx to a PHP FastCGI process.

Posted the static order incorrectly Meant to put varnish ahead of nginx.

You won't gain anything by putting varnish in front of nginx.

Hopefully not so I have one less server to worry about.

I would have to agree. nginx is amazingly fast. I use it in front of tomcat on a couple sites to serve static content. I once did a load test using JMeter from my home machine and got several thousand requests per second with no appreciable CPU usage on the machine.

I wouldn't say it's a "bad fix" if the problem is lack of static content caching. Overkill perhaps as Squid is a very sophisticated bit of software, not just a cache, it can be used as a load balancer, it can be used to map subdomain requests to other ports etc. If you think you may need some of those features in future it may be good to start out with Squid.

For simple caching though, varnish may be the simplest route.

I've noticed Nginx now has caching, and some say that it's faster than Varnish at serving static content..

http://wiki.nginx.org/NginxHttpProxyMod ... cache_path

Another reason nginx is best up front is that it handles gzip compression properly.

What exactly does varnish/squid do that's advantageous to put it before nginx? It caches stuff in memory.

What does the kernel do to disk accesses from nginx if it serves stuff directly? It caches stuff in memory.

So, I doubt there's any real advantage to putting varnish in front of nginx on the same box. Now, if Varnish is on a separate box that does nothing but varnish, sure, that can take some load off. But on the same machine, it's pointless.

None, but there's a good reason for putting it infront of Apache. ( as per OP )

IIRC, nginx can't act as a transparent cache/proxy

Sure it can. Running Nginx as a reverse proxy in front of Apache is a rasonably common deployment.