Re: FN-FORUM: Huge Content Managed site - how to go about it

date posted 15th December 2006 16:22

Mike wrote:
> Thanks both of you. I guess I'm trying to get an answer to a question that
> has no answer :-). Having never priced up a large project before, I'm
> guessing I'll just do the best I can, and if I under or over quote - i'll
> know for next time.
>
> Chris, I think you're right about this - although the site is physically big
> that shouldn't make much of a difference to the CMS structure - i.e. there's
> nothing too complex on there. I already have a CMS I created working for a
> few sites, so I'm guessing I could just use this with some modifications.
>
> Another quick question that has been bothering me a while: the cms I
> currently have just uses a standard template on the front end, and a
> function to call in the CMS content from the database on each page. But now
> I'm thinking that the call to the database is probably unnecessary, and will
> slow the site. I.e. I could simply have the CMS create 'cached' versions of
> each page -i.e. actually print the content from the database to the HTML
> file, so a database call won't be neccessary on each page load, and have a
> button in the backend 'regenerate cached pages' or similar, to remake the
> site with the new content.
>
> Can anyone see any potential drawback to it working this way? And is it
> also that important. I.e. how much would a single SELECT call per page
> actually slow down the site on most servers?

depends how many people are hitting the site...

I have built sites that are static html, but built from a database and
PHP build script (e.g bclm.co.uk) and this works for sites that have
infrequently changing content.

The convenience of a CMS with the stability of a static html site.

The compromise, used by CMS like Drupal is a hybrid where caching in
it's true sense occurs - a master script checks to see if a cached page
exists and serves that unless content has changed, in which case it
creates a fresh cached copy and serves the new content.

the time lost by accessing the database isn't large, but multiplied by
site traffic can be enough to bring a site down (google for
slashdot/digg effect!)

Only you can decide how to construct your site on the scale between
fully dynamic and fully static. and don't forget you can mix the two
philosophies quite well - have the majority of the slow changing site
built into static pages by a dynamic build script and have one or two
fast changing pages all dynamic.

I would be very tempted to look at dedicated hosting for a site if you
think it's going to be excessively busy.

;o)