Updated benchmarks

Ruby Apps Radiant CMS
1

I decided to do a quick run at writing a mongrel handler to do
the work of the radiant cache - turns out there is zero performance
gain in doing so.

Modifying the mongrel handler to serve up html files using xsendfile, I
get:
2014 bytes 534.96 [#/sec] (mean)
2916 bytes 532.33 [#/sec] (mean)
11918 bytes 517.82 [#/sec] (mean)
101920 bytes 414.64 [#/sec] (mean)
1001922 bytes 189.68 [#/sec] (mean)

Adding in the overhead of reading the cache metadata however, slows the
handler back down:
2014 bytes 160.34 [#/sec] (mean)
2916 bytes 151.10 [#/sec] (mean)
11918 bytes 159.20 [#/sec] (mean)
101920 bytes 147.14 [#/sec] (mean)
1001922 bytes 104.51 [#/sec] (mean)

Those are pretty much exactly the same figures as I could pump out of
radiant
without a custom mongrel handler. So it looks like there’s no advantage
in
moving the cache logic into mongrel.

(I also tried changing from yaml metadata to Marshall metadata, but that
also made no difference).

And just for comparison, figures for radiant where mod_x_sendfile is not
used:
2014 bytes 161.23 [#/sec] (mean)
2916 bytes 151.79 [#/sec] (mean)
11918 bytes 147.70 [#/sec] (mean)
101920 bytes 110.64 [#/sec] (mean)
1001922 bytes 35.62 [#/sec] (mean)

And serving up the same pages as raw html with apache:
2014 bytes 2264.03 [#/sec] (mean)
2916 bytes 2341.65 [#/sec] (mean)
11918 bytes 2251.93 [#/sec] (mean)
101920 bytes 1609.84 [#/sec] (mean)
1001922 bytes 565.91 [#/sec] (mean)

(Note these figures are for my hardware - AMD Sempron 3000, 1gb RAM,
7200rpm SATA disks in a raid1 array - the actual figures aren’t
important here, just the differences)

2

I decided to do a quick run at writing a mongrel handler to do
the work of the radiant cache - turns out there is zero performance
gain in doing so.

From my understanding (I’ve yet to verify, but it’s a project for a
client this weekend anyway) Mongrel is reputably not that great at
serving static content anyway, so the biggest performance gain would
be a caching model that provided a path to a static HTML output (akin
to rails) so that Apache/Nginx/Whatever is fronting mongrel can serve
the files directly and bypass anything ruby related.

Now to me it seems that it should be as simple as having the
standard re-write rule you’d have for rails, but instead of looking
for /public/(.).html you’d need to look for /cache/(.).data, and
some additional checks for stuff you know will be in /public (images,
scripts, styles, system if you are using capistrano).

Am I right? I’ve not looked at the radiant code for caching but a
quick look at the output just now makes me think anyone that wanted
to could already be serving up the static content with an intelligent
rewrite rule.

Glenn

3

Glenn,

Yes, but if we’re consistently getting these stats, it’s enough to
handle a Slashdot attack on a single process, potentially. The primary
advantage of keeping Radiant’s custom cache is to provide more control
over the response headers and the expiration of content.

Daniel, thanks for the updated benchmarks. Good stuff!

Sean

4

On Sep 21, 2007, at 4:33 AM, Glenn G. wrote:

From my understanding (I’ve yet to verify, but it’s a project for a
client this weekend anyway) Mongrel is reputably not that great at
serving static content anyway, so the biggest performance gain would
be a caching model that provided a path to a static HTML output (akin
to rails) so that Apache/Nginx/Whatever is fronting mongrel can serve
the files directly and bypass anything ruby related.

Use a mod-rewrite rule to not pass the page request if the file or
directory already exists, should work well.

–
Damien McKenna - Husband, father, geek.
[email protected] - http://www.mc-kenna.com/