Re: Database driven web content: live or tape?

I'd imagine that generating static pages would also reduce load on the web server, make the site faster, and so on. The trick would be regenerating the pages every time the DB changes (in a significant way...), rather than once a night via cron job.

If the site's very dynamic, live updates would be the way to go, but otherwise, I'd be afraid that they'd be a waste of resources.

Update: There's some good discussion on high traffic dynamic+cached sites at Opening too many files?.

-- The hell with paco, vote for Erudil! :wq

Comment on Re: Database driven web content: live or tape?

Replies are listed 'Best First'.
Re: Re: Database driven web content: live or tape? by talexb (Chancellor) on Jul 19, 2002 at 20:29 UTC
I think the solution that's presenting itself now (after more coffee and some thought) is one where I go to the cache for each page .. if there's no hit, I go to the database. Whenever the database gets updated, I flush the cache. So that's the best of both worlds .. database driven, but cached until the database gets updated. Thanks to all for their thoughtful replies!! --t. alex "Mud, mud, glorious mud. Nothing quite like it for cooling the blood!" --Michael Flanders and Donald Swann	[reply]
Re^3: Database driven web content: live or tape? by Aristotle (Chancellor) on Jul 19, 2002 at 20:39 UTC
If you mean invalidating the entire cache for each update, I'd strongly recommend you use an invalidation scheme that at least affects only parts of your cache, if restricting it to just the one affected page is not possible. Otherwise, esp if your site contains a lot of relatively seldomly visited and seldomly updated pages, you'll reap much less benefit from caching than possible. Makeshifts last the longest.	[reply]