Since July, I have been experiencing CPU usages on my Virtual Dedicated Server. In July, my host InMotion Hosting, whom I have had an excellent relationship with for over 3 years, recommended that I should move to a ‘new faster server’ and they would migrate my accounts for free.
Sounded good, I asked a few questions, hoping to make a relatively informed decision, but I know next to nothing about servers and hardware, which is the reason why I turn to them for hosting and Virtual dedicated hosting specifically.
They upgraded me and within about 2 weeks, I started having problems with my account using up too much load on the CPU of the server. My sites and the server were crashing every couple weeks, and InMotion Hosting started telling me that I would have to upgrade to a dedicated server, a price difference of $150 per month! (Currently paying about $50 a month, prepaid for a year, Dedicated costs about $200 per month).
Frankly, I couldn’t afford the move.
At the time this first started happening, I was traveling in NYC for Affiliate Summit, and I didn’t have the time to completely figure out what was going on. Twice over the years, I’ve run into CPU load issues and it usually involved a plugin that was broken or not working right.
I searched through my cpanel accounts, checking the error logs on each. I found a few little errors but nothing significant. I fixed those, checked with my host, and that didn’t seem to phase anything.
I did some heavy lifting in robots.txt to insure that I wasn’t being indexed by bots that were driving up the CPU (there was some indication that a bot masquerading as the cuel (cool) search engine was causing a bit of a problem. I worked to eliminate bot access to every folder that wasn’t essential.
I triple checked my largest sites to insure that my images were optimized too. (they were already, but I wanted to double check)
I was already running WP-Super Cache on my largest 2 sites, so I started loading that up on all my other sites. Then I added DB Cache and even Widget Cache and DB manager so that I could routinely optimize my DB.
That seemed to make a small bit of a dent but not enough.
My biggest problem was really the lack of information at a domain level. On a VDedicated account, I have absolutely NO TOOLS to help me identify if one domain/cpanel account is causing the bulk of the problem or if all domains are. I thinned out the herd and eliminated/suspended/moved some cpanel accounts.
Again that helped just a little bit, but not enough.
Finally towards the end of September, I spoke with a admin at Inmotion who was able to install a script or a program to monitor my account. I couldn’t view this program, but she was able to tell me the top domains or directories that were using the most CPU at the time. She was also able to point out a couple plugins, that were not creating errors but did seem to be consuming to much of the cpu resources. I deactivated and deleted them.
A couple days later, I got a message from Inmotion saying that that action had fixed the problem!
I sent back a message saying terrific! I can’t believe we finally solved this. I was very happy and relieved.
But 20 minutes later, the same person replied again and told me that actually things weren’t fixed and we’d have to continue monitoring.
Uh, OK.
Four days later, I get an email saying that things were still bad, and my account would be shut down tomorrow, the original deadline given several weeks earlier.
So I called in, got filtered through hold for 20 minutes, got a low level representative on the phone, who was nice and polite but frankly jerked me around for 14 minutes because 1) he couldn’t do anything about the issue 2) its his job to make sure that people like me no longer have direct access to the admins 3) their own internet connection was apparently down 4) when he tried to transfer me, it didn’t work a couple times, maybe internet down related.
So I finally get on the phone with the admin who had sent me the latest message. I mentioned to him, that when I had spoke with the helpful representative that had set up the monitoring script, that she had indicated the next thing to trouble shoot would be whether my Apache configuration on the new server was not optimal for my sites as compared to the Apache configuration on the old server.
I asked the new guy if we could look at this. I had done some quick research that had indicated:
mod_php Vs. FastCGI
How you integrate PHP into Apache has performance implications. The two most popular options are:
mod_php
The PHP interpreter and all it’s linked in libraries are compiled into a loadable Apache Module (mod_php) and this module is loaded into every running Apache process at startup time. This is generally the simplest way to run PHP and is supported by most hosting environments. It also introduces memory overhead because of the monolithic Apache processes which you have running, and because the PHP interpreter is included in the web server binary which services non PHP files.
FastCGI
An alternative method of using PHP is to have the PHP interpreter running external to the Apache process and to use the FastCGI API to interface between the web server (mod_fastcgi) and the PHP interpreter. The advantages of this method is that you don’t load the full PHP stack into Apache, you can call upon PHP only when your web server needs to run a PHP script (not images, or HTML/CSS etc) and you also get security benefits of running PHP as a user other than the web server user. This setup is slightly more advanced, and usually requires custom compilation of PHP. One other possible advantage here is that you may be able to run the threaded Apache worker MPM when using FastCGI, since technically any non threadsafe PHP libraries are not being run inside Apache, but inside an external process.
I also found this useful description in a forum post that broke down a few additional settings from someone with the username ‘till’:
The php option depends on traffic that you expect for the site and if the site e.g. uploads or creates images or files on the server.
mod_php:
- fast
- runs not under admin user of the site
- well suited for low and high traffic sites, but not for cms systems like joomla.
suphp:
- not so fast
- script runs under web admin
- secure
- well suited for low traffic sites
fastcgi
- fast
- script runs under web admin
- secure
- well suited for high traffic sites
so basicalley the decision is, if a site is low traffic, use suphp. suphp spawns a new cgi process for every page request, but it does not use resources when no pages are requested. On the opposite fastcgi, the php processes are running permanently even if no page is requested, this is faster and fine for a high traffic site but for a small homepage with 100 pageviews per hour you would waste resources.
So he agreed to try an alternative, and later sent me this message after it had been set up:
Just to follow up with you I have made two major changes to your VPS platform. The first being php was upgraded to the latest (from 5.2.10 to 5.2.11) and no longer uses suPHP. Also I have recompiled apache to use the MPM Worker instead of MPM Prefork which may help to
reduce load used by apache.
So now I’m in a new holding pattern, hoping that this change might be the magic bullet that gives me back my happily functioning websites and vdedicated account. I’m heading to BlogWorld next week, so I expect that my account will likely take a crap on me while I’m traveling, not a traffic spike or anything, just a Murphy’s Law issue.
The post Does a PHP integration of mod_php or FastCGI or suphp have an Impact on CPU Usage? appeared first on TOP 10 TECH.
