Lately, I’ve been having some trouble staying under my monthly GPU allotment. This week Media Temple gave me a call and agreed to help me lower my GPU usage. After spending the week optimizing my site, I’ve lowered my usage by roughly 50%. Instead of keeping the secret to myself, I thought I’d share my optimization tips with you.
What Makes Up a GPU?
Before I could lower my usage, I had to first understand what a GPU is. Since the GPU, or Grid Performance Unit, is a new form of measurement in hosting, there are a number of misconceptions surrounding the unit. Even my original understanding of a GPU was wrong.
GPUs reflect the amount of processing power a site uses on the Grid. The key point here is processing on the Grid. MySQL queries take place on the SmartPool or GridContainer system and are excluded from GPU measurements. GPUs will contain PHP scripts, Perl scripts, and other CPU related tasks.
Tracking GPU Usage
To find out exactly what was consuming my GPUs, Media Temple provided me with an itemized GPU report. To get a GPU report, just send in a ticket to support. In the future, GPU reports will be available in the Account Center with a click of a button.
Alternatively, Urchin provides a quick glance at the most likely candidates of GPU usage. The report to use is called Page Query Terms and can be found under Pages & Files. While Urchin’s report did not point out the smaller pages using my GPUs, the report accurately diagnosed the biggest GPU hogs on my site.
My GPU Report Results
Once I had my GPU numbers, I was surprised with the results. My site’s feed consumed around 50% of my hourly GPU usage. Why? My feed was uncached and running Mint’s Bird Feeder. Not only did WordPress have to generate my feed on every request, Bird Feeder had to acquire information about the subscriber and store it in a database. Since feed readers tend to request a site’s feed in short intervals, my feed was constantly being accessed.
Additionally, WordPress’ Permalink Redirect plugin appeared to be creating multiple requests per page load. If a person would visit the incorrect permalink URL, Permalink Redirect would not run until after the page had already been pulled from the database. Then, the person would have to fetch the correct page’s contents, wasting even more resources.
Finally, I found search engine spiders were hovering around robots.txt, requesting the file several times per hour. I found that odd since I did not have a robots.txt file on my site. Wouldn’t you know, WordPress automatically generates a robots.txt if the file is missing, wasting resources.
How I Solved the Usage Problems
Addressing my feed issue was simple. I just moved my feed to Feedburner. The Feedburner Plugin insured that all my subscribers would not have to change anything to continue receiving my content. More importantly, the Feedburner Plugin moves the feed without any heavy PHP processing, a factor which could contribute to GPUs.
Fixing my Permalink Redirect issue left me feeling stupid. I knew I needed .htaccess rules instead of using PHP processing, but I didn’t expect the results. In my search for .htaccess rules, I came across this post addressing my issue specifically. In fact, so specifically the site even mentioned my name as a proponent of Permalink Redirect! I guess I need pay more attention the blogosphere; there might be some other worthwhile enhancements out there for me.
Finally, I solved the robots.txt access issue by simply creating a robots.txt file. WordPress stopped creating one for me, and my site served up a static file instead.
How to Lower Your Usage
Obviously, my specific optimization are not going to work for everyone, so here are some simple general optimization you can try on your site:
- Cache your site’s content with WP-Cache.
- Uninstall plugins which are unnecessary.
- Look for cached version of existing plugins.
- Look into enabling persistent MySQL connections in your PHP apps.
- Lower your site’s footprint.
Hopefully by following this advice, you too can lower your GPU usage.
One more thing. For Mint users who are using Feedburner or plan to move their feed to Feedburner, I am developing a Feedburner Pepper which will rival Bird Feeder. My Pepper has caching and offers the same functionality as Bird Feeder. Look for a release in the upcoming week, or download the beta now.
Update: There was a bug in GPU reporting. Media Temple is currently working out the issue. You can read more about it at one digital life.
13 Comments
Re: Permalink Redirect
Just want to clarify something Re: Permalink Redirect.
1. Yes the Permalink Redirect is executed *AFTER* posts are loaded and queries are done, however it *does not* run more database queries to ensure the REQUEST_URI is in the correct permalink structure. In fact the extra overhead on Permalink Redirect is minimum on positive hits, i.e. requests coming in the correct URI. It would only be a penalty if requests are not using the wrong URI.
Now, how often do requests come in in the wrong URI? That all depends on how a site is linked. If you pages always show up in the correct URI in the first place (which Permalink Redirect ensures), it is less likely to be linked incorrectly.
2. Permalink Redirect is *more* than just adding trailing slashes to URI, as Alister incorrectly asserted. People use many different permalink structure. One popular alternative is to use .html as suffix in permalink structure to trick the bots thinking these are plain HTML files. Permalink Redirect will guide the traffic into the right URI, whereas a simple .htaccess won’t.
People also use Permalink Redirect to correct old permalink structure (for example you change permalink structure several months after WP site has been setup). It is difficult to do in .htaccess if the new structure is not a subset of the old structure.
3. Permalink Redirect works on various web servers. I use a combination of lighttpd, nginx and Apache on a few of my WP sites, and Permalink Redirect works on all of them — even when .htaccess is not supported.
But hey, you are *ABSOLUTELY RIGHT* — it is actually no point using it in your specific case. Apache would do the work much faster than doing it inside PHP.
Thank you for that informative information Scott. I updated the post to reflect your corrections.
I’ve been running Permalink Redirect for at least a year, and my GPU logs showed roughly every other page receiving an equal amount of 301 and 200 requests. Something must have my links indexed incorrectly.
Hi Ronald,
Yes that is certainly weird. Or maybe not — I have just checked my own stats and have found lots of 301 as well, mostly from bots (with Java in the User-Agent). Some statistics on one of my site:
Page views in correct permalink: 30,515
301 Redirects: 7,649
- Java: 6,101
- Yahoo Slurp: 507
- MSNBot: 179
- Googlebot: 168
- (and quite a few bot-looking UAs)
Now we can all declare that Java is evil
The only thing I don’t like about JavaScript based statistic gatherers is the lack of getting information when JavaScript is disabled or non-existent (like when using lynx)
GPUs… P-U, more like it.
I am on the Grid-lite, because I was ported over to the grid from my previous account. So I only start with 500 GPU per month. I’m not 219 over my allotment.
I was told my Media Temple support how to check on what is causing the soaring number. Page queries in my Urchin stats show my personal blog is the culprit. Well, I’ve had that blog turned off (using the “temporarily unavailable” plugin) for 1 day and I have seen no difference in my stats. I ran a test seeing how many DB queries the page pulls when it loads and the grand total was 18. None of these DB queries are being pulled now because the page won’t load when the plugin is activated. According to my stats, that non-functioning blog is pulling 43% of all page queries. It doesn’t make sense.
On the flipside I have another blog on the same account. The main page has been loaded over 300 times today, and also pulls 18 DB queries. It’s not even listed in the top seven of the page query terms in Urchin stats.
Unfortunately I’m not a big named blogger who can get mt’s attention. But I have brought them two new customers within the past four months and recommend each person I work with into going with mt. Right now I’m looking at an inflating extra charge due to a blog that isn’t online. Great deal!
I actually enjoy that “feature” of JavaScript tracking. Gets rids of all the spam bots from my statistics.
First off, Urchin is only the first step in tracking GPU usage. It can give you a good idea of what’s consuming CPU resources, but it’s not calibrated to (mt)’s GPU system at all. To truly find what’s consuming your resourcing you need to submit a ticket and ask specifically for a GPU report. Let them know Urchin is not being helpful in tracking down your problem.
Next, you’re misunderstanding the GPU. MySQL query time is not counted in GPU calculation. Only processing of the results and whatever PHP has to do to fetch those results.
I’m wondering if a spam bot it hovering around your personal blog. A spam bot could be accessing your site several times a second to try and deliver its payload. I’d look at your stats to see if anything is out of the ordinary.
You don’t need to be a big name blogger. You just need to open a ticket and clearly explain your problem.
Looking forward to the Feedburner Pepper! I’ve been looking for something like that.
Thanks, Ronald, I followed your advice. I contacted MT for the second time re: GPU, unfortunately they referred me to the same Page Query Terms knowledgebase entry and said they had no further info. Apparently you hold more sway over them then I do. I have referred them to this blog entry in hopes of getting an answer.
Cool! Thanks for the tips. Although my own overage was false, it’s nice to have options for optimizing my site (and I need to do it).
Hi Ryan,
Are you still with (MT)? If yes, are you in their (gs) or (dv)?
Hey Forrest, I am still with MT. I requested a GPU report via a support ticket and was told that they could not supply one. So I called MT and after about 25 minutes of long distance charges on my cellphone was emailed a GPU report that detailed my usage for 1.43333333 hours. It was pretty outrageous. No scripts, just jpgs and gifs (for files that aren’t even on the server anymore, but are still requested from outdated searches and hotlinks!) The cover from the CALL OF DUTY game soundtrack was the most requested file and was pulled a whopping 1.5 GPU per hour. Huh!? Anyways, none of these files showed up on the “Page Query Terms” section of Urchin that MT was so fond of referring me to previously.
The insanity of the whole GPU setup was that I was told that in the future, if you went over your GPU MT would email you, let you know, then disconnect your site until the next period. There would be no way to adjust your site based on up-to-date GPU data. Just pull the plug! I asked what an hours worth of GPU data from April would do for me 5-6 months down the road. The kind tech person agreed that it would be useless and we ended the call.
MT has now suspended GPU tracking for the time being, and they kindly wiped the charges from my account (to answer your question, it was a GS account, that was previously a ss account, so I had a measly 500 GPU to start with, and was well on my way to hitting about 800 GPU!) I’m pretty sure if I upgraded to the full grid I could save myself those additional GPU charges, but since the system was faulty I may not need to worry.
@Ryan
Thanks for your updates.
I am now on a VPS which price tag is between a (gs) and a (dv) account. And I am trying to choose one.
Have you ever thought of upgrading directly to a (dv) since it does not has any CPU concerns (as an options) ?
I was pointed in this direction by Arman at (MT), and what an eye opener!
I’d asked for a GPU report, and robots.txt featured quite highly - now I know why! Problem solved in 2 seconds flat.
Also, and this is one you didn’t mention, I had a lot of hits to favicon.ico. When I tried to access the file on my site, I noticed that the entire site loaded! Adding that file should reduce CPU usage dramatically too.
Just thought I’d mention the icon. Thanks for the great advice.
4 Trackbacks/Pingbacks
[...] those of you who are having trouble with GPUs, read my follow up post. I have some helpful tips to low your GPU [...]
[...] You Need Permalink Redirect? Via CaveMoney50, Alister Cameron wrote about Two WordPress Plugins You Don’t Need and Shouldn’t Use. [...]
[...] แต่เดี๋ยวก่อน ก่อนจะใช้งาน ถ้าเวปของท่านมีคนเข้าใช้งานเป็นหมื่นเป็นแสนในแต่ละวัน plugin ตัวนี้อาจจะไม่เหมาะก็ได้ CaveMoney50 ได้กล่าวถึงการใช้งาน GPU อันหนักหน่วงอันเนื่องจากโปรแกรม และ plugin ใน wordpress และ alistercameron ก็ได้พูดถึง plugin 2 ตัว ที่ไม่ควรใช้มากที่สุด Technorati Tags: permalink redirect plugin, wordpress plugin [...]
[...] Lowering My GPU Usage on Media Temple’s Grid-Server I’ve been considering a switch to MT since Dreamhost’s performance has been terrible lately. (tags: web hosting apache) [...]
Post a Comment