# Updated benchmarks **URL:** \ **Category:** Radiant CMS\ **Created:** [September 21, 2007, 2:17am UTC](https://www.ruby-forum.com/t/updated-benchmarks/115150 "2007-09-21T02:17:11Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [September 21, 2007, 2:17am UTC](https://www.ruby-forum.com/t/updated-benchmarks/115150/1 "2007-09-21T02:17:11Z")
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) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [September 21, 2007, 10:37am UTC](https://www.ruby-forum.com/t/updated-benchmarks/115150/2 "2007-09-21T10:37:01Z")
> 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 ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [September 21, 2007, 2:23pm UTC](https://www.ruby-forum.com/t/updated-benchmarks/115150/3 "2007-09-21T14:23:46Z")
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 ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [September 21, 2007, 2:40pm UTC](https://www.ruby-forum.com/t/updated-benchmarks/115150/4 "2007-09-21T14:40:49Z")
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. removed\_email\_address@domain.invalid - [http://www.mc-kenna.com/](http://www.mc-kenna.com/)