MediaTemple Grid Service Benchmarks
Posted by Lance Ivy Tue, 18 Dec 2007 23:27:00 GMT
I’ve been working on a deployment on the MediaTemple grid service, which on the surface strikes me as a very smart way to manage Rails apps. Putting shared hosting on a grid layer mitigates the performance spikes associated with of sharing a box and the overall limitation of the box’s resources, and putting the Mongrel threads in their own environment with dedicated resources shields your Rails apps from the weirdness of shared environments. Cool.
Been having some trouble with disk speeds, though. Capistrano deployment is just dead slow. So I decided to do some benchmarks on basic deployment-related commands to get an idea of the magnitude of the problem.
Benchmarks
`time -p svn co -q http://subversion.host/path/to/repo test_dir`
| Desktop | Grid | |
|---|---|---|
| real | 34.45 | 155.97 |
| user | 2.41 | 1.57 |
| sys | 1.18 | 2.89 |
`time -p rm -rf test_dir`
| Desktop | Grid | |
|---|---|---|
| real | 0.22 | 15.58 |
| user | 0.02 | 0.02 |
| sys | 0.20 | 0.58 |
Conclusions
I’m not going to assume that just because file writes and deletes are slow, all disk reads are slow. But there’s one thing I do feel justified in concluding: it’s a problem with the filesystem or the disk performance. This isn’t deductive reasoning, but this is how I figure:
- Subversion checkouts have less slowdown than removing files.
- Subversion checkouts are a combination of network travel (my repository is at Assembla) and CPU time (to set up working copy) and basic file operations (adding files).
- Removing files is just basic file operations.
Therefore, basic file operations are the bottleneck, not network latency or CPU cycles. Of course, since this is a managed system I can only guess.
Keeping Perspective
I am not a Linux benchmarking expert. I have no idea how my desktop specs compare vs the grid servers. Any grid service is going to have some slowdown from the abstraction, just like any VPS.
But the biggest thing to remember? These benchmarks probably don’t matter for Mongrel performance or database access. Remember that in MediaTemple’s grid, Mongrels have their own container and the database may very well be in different environments as well. With a managed system like this, it’s just hard to tell.
Subscribe
I had a client who was hosted on media temple when I arrived at the project, and it turned out to be an absolute nightmare. I had all sorts of ruby-gem compiling issues (wrong or missing shared libraries). Being able to install your own gems on media temple is nice, as long as you don’t rely on compiling the extensions.
In one case, I used a static compiled gem for rmagick. That didn’t even work, because they had the wrong version of libtiff.
Another thing that drove me nuts was speed – MediaTemple was slow!
Also, they’re virtual container thing would kill our apps and not do us the favor of starting them back up again… so we’d have random downtime.
This was my experience with them (about 6 mos ago). I don’t know if they’ve improved their service since then.
Was this the VPS or the Grid? We tried the VPS at first, but it didn’t look like any Linux distro I recognized, and combined with the Plesk offering looked more like a vehicle for resellers.
It was the Grid, not VPS. Perhaps they’ve improved things considerably since we left them :)