Performance: What do You think about writing nodes and blocks to static files for special purposes ...?

Hi

There are already some initiatives on this site, which point to the same direction:

Focus A: server load / response times

Focus B: integration with outer pages and content, even toher sites.

About Focus A:

How to avoid that high load situations get to much of a burden for the site engine?

Lets see:

under normal conditions every page and block produces several MySQL-requests, which is softened by different caching approaches: the general drupal cache and the new block cache for example.

But even these will produce database requests - eventhough less than "normal".

In a tough situation, where the bottleneck may not be the server itself, but the database connection, alternatives may be valuable, in order to reduce the overall load on the system.

So here is the thought I would like to share and eventuelly request not only Your opinion, but also some hand for coding the solution - which I can not do, because I am not a programmer.

Payment can be discussed.

1) Bottleneck nodes / feeds:

It was a simple excercise to see the impact in this topic.

The more modules and the more languages You install, the slower is the response.

Just for curiosity, we setup some 50 modules, plus some 20 languages, and almost fell asleep during while pages where produced and loaded : average times of over 67 seconds where no exception,

Serverload for node and feed request on shared hosting is therefore a hot topic.

Lets face it: what kind of worth can a CMS have by the variety and diversity of modules and functions, when these are almost unusable in real life situations.

Approaches:

There was a shy intent to have a module saving whole sites as static html versions on the server, and then only request the database, when certain conditions appy (aged, outdated pages, etc.) .

I do not know if this approach was totally abandoned, or if there is somebody working on it.

Question:

How difficult would it be, to just produce a plain html or text version of every page and every node or block so it can be referenced from within or eventually event from outside the server.

This seems specially important also for feeds and sitemaps, as they produce database queries with every request.

2) Bottleneck blocks:

In this point I would like to differentiate normal block operations, which we already can cache.

The other topic is integration of DRUPAL with none Drupal parts of a site or a site network.

Please see this scenario:

1) transition of sites: many sites have a history which is "no database" but a start with static pages.

Those sites many times have already implemented lots of solutions - may it be CGI/Perl or PHP from different sources.

To move such a old big site completely into Drupal seems to be a kind of adventure and especially a very complex, time consuming and most likely expensive task.

Why ?

Maybe not all functionality can be produced upfront by Drupal, so we have a problem.

So You may what to stick with some older scripts (agenda, links, etc.).

How to "join" such sites - step by step ?

The linking parts between the sections or parts of a site or site network are basically questions of

(A) menues / links and
(B) design / CSS.

Both joins can be done, for example with files or pieces of code which are inserted as needed in either version:

---- Drupal (The new site) would produce blocks or nodes, sitemaps as static elements.

---- HTML static old site would call those blocks or nodes to insert them as needed within the old structure.

By this approach You can move slowly, as needed. Maybe add blogs to an old static site, whithout the need to redo everything from scratch.

Additionally:

Under really high load, or a broken server, the system could be switched to static pages, so that server operation can continue somehow, whithout loosing contacts.

RESUMEE

imho it would be really great to have the option to save pages (themed or unthemed), nodes, feeds and blocks as static elements in a special directory structure - maybe we call it "/static/., so they can be called by what ever process a webmaster may need or create in oder to join different parts and versions of his site.

How difficult would this be and how much would it cost to make such a solution ?

Best regards,

Roland
Centroamerica.TV
A project that envisions partnership and
cooperation among media professionals.

http://www.centroamerica.tv/