Sean, Would love to look into this further and help out at all if I could (and find the time) as I'm currently serving a predominately static site with Nginx in front of a couple of Mongrel instances, if I could have a rails-style caching method it would essentially make Radiant the admin front end to managing the content and regular end-users would never get anywhere near anything looking like ruby. So speed should be awesome, and I can deploy an extra few sites on the same hardware.
Glenn On 13/09/2007, at 9:44 PM, Sean Cribbs wrote: > Loren, > > As Aitor suggests, it sounds like this site could really use some > caching that reminisces of Rails' page caching model. > > In a non-Radiant site I have worked on recently, the entire public > site > is page-cached, but each page takes a long time to generate (lots of > data, averaging 3 sec/page). A cron job runs about every 30 minutes > that does three things after updating time-sensitive data: > 1) Rename all the cached .html files to .htm (the web server has a > rewrite rule to defer to .htm if .html isn't present) > 2) Hit each page on a separate app-server process that isn't in the > proxy pool, resulting in a cached .html > 3) Remove all .htm pages > This way, we never serve up dynamic pages to users. > > Now, I imagine one of the largest slowdowns on your site is going > to be > Page.find_by_url because it is recursive. Radiant could really be > sped > up by caching the URL in the database, which would reduce lookup time > for most pages, and having the recursive method as a fallback. If you > want, we can hash over the design of this optimization together > (perhaps > with John and Daniel) and apply it to the core. > > Sean _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
