Creating static pages from DB on schedule

Hello Monks,

I'm not completely sure i'm describing this problem correctly, as it's unlikely this hasn't been done somewhere already, but google-fu has failed to help. I ask for your patience in the reading as it's probably a case of "why not use X?".

Situation is as follows:

I have a large (>1m records, between 20-300 linked attributes per record) data set in place through a somewhat slapdash combination of TT and DBIx::Class:Schema. This works, but with the quantity of users accessing it, it's beginning to show cracks.
The major feature of this platform is Multimedia also known as Really Big Files. The pages around it are really just window dressing, but window dressing that will change just frequently enough to need ease of adjustment.
I have enough familiarity with DNS to make the Big File Hosting seperate and balanced through a bunch of seperate servers, but I do not know enough about distributed databases to make them work with the resources at hand.

Thus what I would like to make is a collection of static database pictures through TT/DBIx, but one that can be bulk updated when a suitably large change to the underlying data is applied at frequent intervals. The situation where every single item has to have a database hit for no reason is just a waste of (limited) resources.

I've finally got enough familiarity with supporting modules to start applying Catalyst, so the re-write will possibly be my first full foray into it. The ideal would be if this function already exists within Catalyst.

Thanks for looking

Comment on Creating static pages from DB on schedule
Re: Creating static pages from DB on schedule by moritz (Cardinal) on Nov 24, 2012 at 11:00 UTC
A common approach for increasing performance is just to use caching. In a way, generating static files is one form of caching, but there are others that you could consider, which might be easier than a rewrite of your application from dynamic pages to static pages: You can cache at the DBIx::Class level You can cache on the Catalyst level (probably requires more code changes, but gives you fine-grained control over what to cache). You can cache at the webserver level. For example with Apache, you can use a caching reverse proxy. If the caching rules for your site are easy, this might be the solution with the least code changes. In any case you can invalidate the whole cache when there are big updates to your database. Perl 6 - the future is here, just unevenly distributed	[reply]
Re: Creating static pages from DB on schedule by CountZero (Chancellor) on Nov 25, 2012 at 08:07 UTC
If your semi-dynamic pages are made through a single subroutine call (or you can wrap the rendering of these pages in such a call) then Memoize might be something to look into. It has the possibility to "cache" the calls to this subroutine to disk if necessary. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James My blog: Imperial Deltronics	[reply]


go ahead... be a heretic
	PerlMonks

Creating static pages from DB on schedule

The best material for plates (tableware) is: