Decaflon

OK, let's up the ante. 1 point will be given to the first 13 participants in this survey.

Interesting no one has responded yet. I'm interested to know as well.

If you are afraid of saying something publicly because Jason (from Media Temple) is active in notes do not be afraid. Jason is a super cool dude and he won't nix your hosting because you say something he doesn't agree with.

I've always said that picking the right blogging tools is important. One of the reasons I went back to Expression Engine is because I know I want the site to be high-traffic and there are tools to manage this built in Expression Engine (throttling, caching, etc.). I don't want to deal with add-ons because many aren't really efficient...they work though. :)

So please share your thoughts. It can be a learning experience for everyone. :)

Exactly. MT has nothing to hide. I'm not out to defame anyone. I'm honestly just looking for some numbers. The points offer still stands.

I am actually leaving media temple myself this month so it's a bit ireelevant me saying anything and I'm still on the ole system as never had the 'courage' to go to the grid. I also am still pottering on older wp as a result of not having gone to the grid.

My reason for leaving MT? Cost, response or lack of to support, the grid and the fact of saying they would move people over and never have as never stable - yes you can move yourself but with the problems I've seen people having I simply can't afford the time at the moment to go through potential issues. I could get lucky but I don't want to risk it and simply don't have the time to deal with what the move could hurt for the 4 sites I've got - 2 on each hosting at the moment.

Whilst cost seems a pretty 'lame' reason it's more the fact that I can have multiple hosting (I've got a list of 6 sites I want launched this year including applications which are resource heavy) and I don't / can't afford to do the dedicated option as they are trickling through over the year -yes, at the end of the year it could make more sense but to me it works out better one by one unti then. I also want a ruby testing place as starting to get more and more into that and this move gives me one without the before mentioned grid potential muttering.

I was happy with MT and really it's not a 'happy issue' that prompts this move it's one of fiscal and sensible sense. I did have a few support issues but nothing to make me rant too much and every service fails sometimes. I live in the UK and it's just going to make more sense for me to have UK support times. i'm going in with someone else to get a good deal on bulk hosting - again works for me. I just feel I'm better off somewhere else so moving. I don't like the grid issues but also think a lot of the bad rap MT get is not deserving. Potentially one day I could be going for my own dedicated over there but for now the option I have gone with works better.

5thirtyone.com is powered by WordPress and hosted on Media Temple. Was previously hosted on DV Base but after a recent digg I upgraded to DV Rage. I was completely flustered over a monday morning digg that caused my site to become unresponsive on the DV Base. Slower than frozen molasses.

Anyway, to answer your questions:

1. Feeds on Feedburner.
2. Not sure where to look for GPU but I'm in Plesk > Virtuozzo > Resources and System Resources is at 27%
3. ~240K for page views.

@karmatosed: if you don't mind saying, where do you plan to take your business?

I've been with (mt) for just under a year, the entire time running a non-optimized copy of WordPress as the main site. On the (ss) Pro plan, that is. As I'm mentioned around here in the past, I've yet to "upgrade" to the (gs), primarily thanks to credit cards being a hastle for me to borrow just so (mt) can refund the rest of my year's payment and then charge me for a new term. With that comes some bonuses though; I don't have any of the issues others are having with the grid's MySQL, and performance is a bit better. No worrying about passing my GPU limit or needing a MySQL grid container, yay!

My site hit Digg's front page a few weeks ago now, and took on 20,000 hits in about two days. Despite forgetting to enable wp-cache and offering a couple MB .zip with the post (2000 downloads before I had to take it down), the site didn't even slow down. A Digg can take down Derek's (dv), but doesn't do anything to my (ss)? Fine with me. I'd like to attribute that to the fact that there's nearly no one left on my (ss) server, but who knows.

But while the product is working great, (mt)'s support sucks. A previous [simple] issue took something like 25 replies to resolve, because the (mt) staff kept sending irrelivant automated messages. [Already Jason'd.] The ticket I submitted letting (mt) know of the Digg took two days to get a single response. I guess it's not the end of the world as you don't need support that often, but it's still dissapointing.

Anyways, here's the direct answers to the questions:
1. FeedBurner, so that I can see how many people are subscribed. (I signed up long before Mint 2 came out.)
2. n/a :)
3. Three month average: 10,534.

1. feed: FeedBurner

2. My GPU stats have dropped significantly since they started tracking, but my traffic has only been increasing. From my uninformed perspective it would seem a lot of it has to do w/ how they're optimizing their grid. If this is true it seems a little silly to charge for GPU overages when they lean so heavily on (mt)'s ability to manage load. Somebody correct me ...

3. page views: Urchin says ~250k but I think that's really high. Mint says ~20k "total visits".

Justin, so the top-most number, 623, is the most recent month's GPU usage?

I've been on a (dv) base for several months, and am using WordPress as my blog base. I have been pretty happy with it, though it is largely because I spent a week optimizing it to run well. As it's configured by default, it has a tendency to explode under stress unless you take measures to prevent this from happening. I was able to survive a DIGG onslaught and serve a peak 2750 pageloads in a single hour without incident. I've been keeping notes about the optimization on my blog if anyone is interested. The major cause I found was that the default mail and web server processes were allowed to grow beyond what memory the (dv) base can reliably handle. Secondly, there are some wordpress plugins that are quite inefficient that I had to disable.

I'm running a few sites on my (dv), and it's a great platform once you have learned your way around it. My daily numbers for all sites are fairly low, maybe 10K pageloads a day on average, about half of those from a Phorum installation. When I do notice performance problems, it seems to be due to network congestion more than server problems. I have seen higher latencies from (mt) than other services, and sporadic spikes of unavailability that I mostly don't notice.

Hrm.. interesting questions..

It should be noted that Wordpress itself doesn't actually generate that much load - rather, it's the associated database activity that is really any kind of load culprit.. so obviously, a highly active db (either from masses of writing and commenting, lots of inefficient DB heavy plugins and or raw hits against the engine) will start to punch into the GPU count.

That said:

1: feedburner (doesn't everyone?) ;)

2: Total (out of 1000)
379.00 - (current month)
329.00 - (last month)
147.00 - (month prior..)

3: urchin reports circa 130k as a monthly average, but again that's a tad high.. internal metrics suggest closer to ~ 10k as being more likely.

Crap, meant to mention that I'm on the gridserver (gs) product.

1. Feedburner.
2. march = 74, prior to that, I was in the mid to high 40s.
3. avg is under 600 (yes I know that's weak...but two months ago was over 600 and last month was over 700, FWIW). http://jerrychacon.com/mint/

frotzed, yes, top most number is several months ago, and downward becomes more recent.

First time on notes; the subject relates to me directly so i figured, why not give my $0.05.

My site is franticindustries.com. I'm hosted with Media Temple, use Wordpress, and FeedBurner for managing my feeds.

I have between 40k and 120k monthly pageviews (edit: oops, not pageviews, visits. The pageviews are 70-150k) (depends on Digg/Reddit/del.icio.us traffic), and my GPUs were always very near 1k, until last month when they actually went up to 1136. Interestingly enough, it was the month with quite lowish traffic (e.g. no Digg spikes).

Overall, Media Temple works well under stress. I've been slashdotted, dugg and reddited and the site didn't blink. They did have their quirks with occasional MySQL problems (not related to the traffic) but those seem to be mostly fixed now.

Hello Again 9rules.

all you with GPU questions..please, contact support and have them generate a GPU report for you. This will show you what processes are creating how much load and give you an idea of why your GPUs are increasing or decreasing.

Cheers!

Jason

After freaking out late last week, I've been working with (mt) to lower my GPU usage.

First off, a lot of people think the GPU contains database usage. I was under that misconception, too. Talking with (mt), GPU usage only counts CPU processing time on the Grid (MySQL is on the SmartPool system). Query time will not affect GPU but processing of the data will.

I've found a lot of dumb minor things on my site that were greatly affecting GPU. For one, running an uncached feed. Since moving my Feed to Feedburner I'm down about 30% of usage. I'll have more tips like that later in the week, when I write a blog post on the subject.

To answer the original question,

1. Now on Feedburner, past GPU usage was uncached feed.
2. ~500-600 GPU a month. Was on (gs) lite, so I had overages.
3. Mint tells me ~50,000, Urchin tells me ~225,000

We have a Wordpress site on mt's (gs) servers: http://www.weddingbee.com.

1. We use Feedburner for our feeds.
2. Our "actual" GPU for the month starting on 4/8 is 1,866, so we're already 866 over. Our "projected overage" for this month is 2,007!
3. According to Google Aalytics, since 4/8, we've served 264,109 pageviews. This equates to roughly 7.1 GPU per thousand pageviews.

Our projected overage is $200! I'm pretty desperate to find ways to reduce GPUs, so I'll be following this thread closely.

Thanks!

-Bob

Hey Bob,

have you requested a GPU report from (mt) support yet? This could help you out.

Jason

@Bob: This may be of use to you too.

Yes, thanks for the tip, Jason, I requested a GPU report (req #224453) and I'll try to glean insights from it.

And thanks winnopeg, cavemonkey's article was cool. :-)

Re: cavemonkey's points, we already use wp-cache and Feedburner, but I made the persistent connection change that cavemonkey mentioned, hopefully that will help. I've also created a static robots.txt file, which is a neat idea although it will only save me 0.5% of my GPUs.

Actually, I should mention that I was just told by a (mt) customer service person that "You might want to try disabling the wp-cache plugin as it is known to be quite resource-intensive." However, I didn't try this because I think this will severly hurt performance on a 30k pageviews/day Wordpress site.

It does seem ironic to me that the GPU system (which doesn't count MySQL queries) seems to encourage (mt) users to put more load on the database (which doesn't count for GPUs), instead of on the webeserver (where GPUs count). To be fair, webservers do have to process database query results, and without easily available GPU stats, it's hard for me to tell which would generate more GPUs.

One thing we just did was to change the Wordpress setting to lower the number of posts-per-page to 10 posts (down from like 20). I'd like to go even lower (5), but baby steps...

I'm also going to try adding some .htaccess directives (http://httpd.apache.org/docs/2.0/mod/mod_expires.html#expiresbytype) to cache gifs/jpgs/css by the browser.

Hey, has anybody else noticed that the price per "normal GPU" is $0.02 ($20 month/1000 GPUs) and the price per "overage GPU" is $0.10?! That's a pretty HUGE overage premium, right?!

Jason, on that note, can you tell us if (mt) intends to offer larger plans, e.g. $40/month for 2,000 GPUs or $60/month for 3,000 GPUs?

Thanks,
Bob

Just to give a comparison, we use MovableType and average about 160,000 page-views a month and the GPU usage is about 160 per month.

@Article19: That's interesting. I have a strong feeling that this is a WordPress issue more than a Media Temple issue.

Article19, are you using dynamic templates or static? If you're using static essentially your running a website using pure HTML and no server processing. The largest factor of your GPU would be then building your pages, which only occurs on new comments and posts.

bobbyh, maybe don't take my advice on pconnect. I've been playing around with it, and it appears that perhaps usage is lower with a regular connect. pconnect is weird, so it greatly depends on the number of visitors and what they're doing. I'll let you know what my final outcome is.

Another tweak which I just instated last night is enabling Bad Behavior. Bad Behavior is keeping the spammers out of my site, which appears to have created a 30% reduction in GPU usage from my already lower GPU number. Looking at my logs, spammer were hitting my uncached comment posting file thousands of times per day. Since there is no way to cache that file, that's non-stop processing. BB adds a slight bit of overhead for normal visitors (5-10ms), but saves in the big picture with spammers. Using BB will of course greatly depend on your spam issue.

I'd like to also play around with the difference between Akismet and Spam Karma 2. I suspect SK2 is the lesser of resource hogs since Akismet involves constantly checking an outside service, but I'm not positive. When I get to testing the difference, I'll let you know.

we use static templates, no need for dynamic.

Cavemonkey, thanks for reporting your Bad Behavior test! I have wanted to do that, but I was worried that the associated processing would cause GPUs to spike. I'll install that today, and update here with results.

I just moved back to Media Temple but now am using Textpattern for my CMS. I'll report anything of interest here once I start seeing how the GPU usage goes.

What prompted the move back, Ben?
Was there a problem with the new (old) host?

No, no problems at all. ASO is great. I got on the line with some support staff at (mt) and we worked things out to where they'd work with me to reduce my GPUs.

Thanks to everybody's advice, I've made a number of changes to my (mt)-hosted weblog in an attempt to reduce GPU usage, but I'm running into a problem. (mt) only tells you your current GPU usage, with an unspecified amount of lag. This makes it hard for me to see daily GPU usage, which I could correlate with Urchin or Google Analytics data to see whether my changes are reducing GPU usage.

I guess the only option to get daily GPU usage is to set an alarm for midnight, and click refresh to find the current GPUs, and then subtract from yesterday's GPUs?

I opened a ticket with (mt) on Monday to request a daily breakout of (GPU), but I haven't heard back from them.

How are other people dealing with this?

Thanks,
Bob

1: Feedburner
2: Last three months of GPU usage 421, 452, 1009
3: Corresponding period PV amounts 53k, 58k, 77k (this represents 95% of the traffic hosted on the site and is pulled from Google Analytics)

This month we have had further traffic growth, but in response to the CPU overage we had, have been fixing some issues which had been misoptimized. Most of these issues had to do with 404 errors where WP was loading a full page when getting an error, especially with favicon.ico files. We also turned on WP-Cache for some of our traffic. Now our runrate should be 700 GPUs.

Not happy with a blackbox statistic which is not transparent being the limiting factor of my hosting account and we have not been happy with MT since we switched over in late 2006 with numerous performance issues, erratic availability and generaly flakiness. That being said, they seem to have been slowly improving the grid. Transparency on the GPUs would go a long way. But end of the day, it seems like a lower value than what you get from other hosting companies. 3-4k PVs per day is NOT a lot of traffic but that seems to be the max WP traffic you could get with 1000 GPUs.

Also I just got a note from them indicating they there is another glitch in their GPU calculations somewhere and they are voiding any overage charges since 3/10/07 and

"2) In the best interest of our customers, all GPU accounting and overage fees will be disabled pending a full, forensic analysis of our GPU accounting system.

3) A new GPU analysis tool is being developed to give you an incredibly detailed view into your GPU usage. This new tool, currently in development, will help you track scripts, software, and files which are causing GPUs to be used. We will be providing further updates on this tool on our weblog."

I knew something wasn't adding up.

bobbyh, I've just been checking my GPU, keeping a log of the time accessed and GPU at the time. I've been able to fairly accurately measure my GPU that way.

By the way, I just logged into my Account Center to see the following message:

This component is currently being upgraded to provide more accurate reporting. GPU accounting for your site has been temporarily disabled.

johnnydebacle, I did think something was up as my GPU surged this past month, prompting my overage which lead to me and (mt) working on my GPU issue.

Thanks for looping back in, cavemonkey!

Yeah, the GPU usage did seem a bit crazy. I look forward to the "incredibly detailed view into your GPU usage" that they're building! :-)

(mt) is trying to do something totally new here, so I'm not surprised they're running into problems like this. On the plus side, I'm impressed with how they handled the issue. Props to (mt) for giving refunds for GPU overage to users while they sort this out.

I just talked to (mt) and GPU calculations will be disabled until they are completely sure of their algorithm. They will keep us updated on the (mt) blog.

All customers who experienced GPU overages should have gotten this email: http://www.onedigitallife.com/2007/04/26/media-temple-false-gpu-overages/

So, if you experienced a GPU overage since 3/10/07 and haven't been refunded, contact (mt) and they'll refund your account.

I can now say from personal experience that changing to persistent connections is a Really Bad Idea. Those persistent connections take 60 seconds to die, so if you hit the db more than 60 times a minute, you will max out your "max concurrent connections" to your database, your site will die a horrible death... So listen to Cavemonkey, y'all, he did warn me not to use pconnect! :-)

Are you experiencing that issue personally? Unless all connections happen at the same second, you should not reach your connection limit. The whole point of pconnect is to reuse connections not open more and more.

Come to think of it, my experience may not have been a clean test of pconnect versus connect, so I shouldn't have said that pconnect is bad.

I'll post exactly what happened though, because it resulted from another optimization change I made after reading this thread. I installed the Bad Behavior plugin at Cavemonkey's recommendation, and it worked great. I also made a slight change to wp-cache's PHP to integrate the two plugins.

Anyway, a few days ago, I tried to figure out why my site threw the occasional 500 error. Eventually, (mt) said that there was a "cluster node acting out of normal operational ranges", and they fixed it. But while debugging the error, I turned off the Bad Behavior plugin while NOT turning off the wp-cache plugin. However, because of the integration change in wp-cache, wp-cache was still invoking Bad Behavior code, which caused problems. Turning off the wp-cache plugin eliminated this dependency (in an indirect way) and "fixed my site".

However, this morning, because wp-cache was turned off, my database was maxing out the number of connections. I changed from pconnect to connect, rebooted my MySql container, and that resolved the problem.

I looked into this, and I think this might be the issue.

Anyway, now that this is fixed, I've already turned Bad Behavior back on, and tonight, I'm going to turn wp-cache back on.

Sorry if my story is boring. But perhaps it will help somebody else who faces a similar problem!

-Bob

Interesting. Maybe pconnects don't work so great on a Grid platform since every page request has the potential to be coming from a different server.

I'm changing my pconnects back to connects. Thanks for the info bobbyh.

Cavemonkey, I forgot to mention that you can see for yourself how many connections to mysql occur with pconnect versus connect on your machine. Log into phpmyadmin, and click Processes. When I had pconnect on, the number of processes hit 61 and they filled the screen. The "oldest" connection was always around 60 seconds. When I switched back to connect, I only had one or two connections.

If you have wp-cache on, you may want to turn it off during the test to have Wordpress hit the database more...

If you look at this, please report back! :-) I'd be very interested to see if you could replicate this and thus prove that pconnects don't work so great on a Grid platform.

Thanks!

-Bob

I turned wp-cache off and enabled pconnect. phpMyAdmin reported only a 1-2 connections the whole time. What I would see is a command query, then if I refreshed the page quickly I saw the same query issue a command sleep, then the following refresh disappear. A couple of times I saw previous query IDs coming back, most likely connections held open, following the same behavior as before. Doing the same with a regular connects worked in the same manner without seeing the sleep command and never seeing the same query id come back.

Are you seeing a sleep command generated at all? I wonder if something is borked on a particular grid node and doesn't properly sleep pconnections.

Cavemonkey, I can't replicate the pconnect behavior anymore, so now I think it was my particular grid node at that time, as you suggested. (mt) did say that there was a "cluster node acting out of normal operational ranges", so there was a confirmed error.

Sorry for the confusing bug report. On the plus side, now I know that if connects or pconnects ever go mad, I can click on the Processes tab in phpmyadmin to see if I've maxed out the # of connections. :-)

Also, if I "connect" wp-cache and Bad Behavior, I shouldn't turn off only Bad Behavior! :-)

Thanks,
Bob