Search code examples
nginxwebserverfastcgivps

Assistance optimizing server with high-traffic


I am in need of some help. Currently, I have the following package:

2048 MB 80gb RAID 10 Disk Space 4x CPU Priority 5000 GB bandwidth CentOS

(VPS-4) http://www.knownhost.com/vps_packages.html

My VPS has been receiving a lot of traffic. It had 1 million page views on one day, even!

As cool as that is, we have been plagued with problems ever since the dramatic rise in hits.

We were using SuPHP at first, which was getting resource-intensive. The server would go down every couple of days and we would receive automated emails about excessive processes running.

We then switched to FastCGI. This has been running great and we stopped getting those emails. However, during peak time, if there are a lot of people connected, then web pages wont show. You will have to refresh the page a couple of times to get it to show (sounds as if all connection slots are held up).

We are currently using NGINX + Apache w/ CPANEL + eAccelerator + FastCGI on this server.

Ignoring the current setup configuration and keeping in mind the hardware we are using, do you guys have any suggested configuration that may be best at supporting all these hits?

Please keep in mind that the large amount of hits occurs one ONE page (don't ask!). The page has barely any PHP on it (but is partially dynamic so the PHP is needed) and doesn't even connect to a database.

Thank you very much.


Solution

  • Throughout this, I will modify the nginx config. Apache can stay as it is.

    Step 1: Deploy gzip compression

    This step is pretty simple - gzip-compress output.

    gzip             on;
    gzip_min_length  1000;
    gzip_proxied     expired no-cache no-store private auth;
    gzip_types       text/plain application/xml application/json;
    

    All that this will do is enable gzip compression for: text/html (default), application/xml, application/json and text/plain. I'm assuming that you are serving images from CDN, by the way. If not, enable that for them too.

    This should see a drop in your used bandwidth, but offset this by a slight CPU cost. However, CPU is rarely the bottleneck - usually, it's bandwidth and disk I/O, especially on static sites, so we're going to be working on that.

    Step 2 (optional): Drop apache if you can

    If you're just serving static content, nginx by itself is worth having. If you're using fastCGI already, consider PHP-FPM, which allows you to short out the memory hog that Apache is.

    Step 3: Caching through headers

    This will lower bandwidth usage by forcing a locally-cached version of all pages served by nginx. Pretty cool stuff as it will completely prevent clients from re-downloading something they already have.

    expires       24h;
    add_header    Cache-Control  public;
    

    This step will also have an unsought advantage: apache will get fewer queries.

    Step 4: in-memory page caching

    This step will take your page out of disk I/O and into memory. If you have one static page, you should see a significant gain by doing this. this question has a lot about this. Covering it would take a serious amount of time.

    This will have two advantages:

    • nginx will more often load from memory rather than querying apache, reducing in a lighter load on Apache
    • Apache itself, due to this, will read from disk and fork workers less often

    Once all this is done, you should see a decrease in load, possibly enough to lower the number of workers on Apache.