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 Glenn Gillen wrote: >> 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 > _______________________________________________ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > _______________________________________________ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
