Why not generate static pages instead of dynamic?

[pittendrigh]

There must be millions of dynamically generated
html pages out there now, built by on-the-fly php code
(and jsp, perl cgi, asp, etc).

Programatic page generation is transparently useful.
But querying a database, negotiatinig lots of if-then-else logic
and echo'ing html code out on port 80 every time a
page is requested has to be a huge waste of resources.

Why not use that logic to print static html instead of dynamic?
The few pages that need to be dynamic (perhaps the results of a
database
query) probably represent only a small fraction of the total
number of pages that are rendered by on the fly code.

Seems to make sense to me. All you need to do is work
the output directories into your code logic somehow,
and do a few one-time-only mkdirs before printing out the static html.

Am I missing something?
Why is it so little open source page generation software acually
works that way?

[Ivan Marsh]

On Mon, 16 Oct 2006 12:33:19 -0700, pittendrigh wrote:

There must be millions of dynamically generated html pages out there
now, built by on-the-fly php code (and jsp, perl cgi, asp, etc).

Programatic page generation is transparently useful. But querying a
database, negotiatinig lots of if-then-else logic and echo'ing html code
out on port 80 every time a page is requested has to be a huge waste of
resources.

Why not use that logic to print static html instead of dynamic? The few
pages that need to be dynamic (perhaps the results of a database
query) probably represent only a small fraction of the total number of
pages that are rendered by on the fly code.

Seems to make sense to me. All you need to do is work the output
directories into your code logic somehow, and do a few one-time-only
mkdirs before printing out the static html.

Am I missing something?
Why is it so little open source page generation software acually works
that way?

If a page has information on it that changes depending on the desired
content it cannot be a static page, otherwise it is a static page.

I'm not sure what your confusion is.

[Moot]

pittendrigh wrote:

There must be millions of dynamically generated
html pages out there now, built by on-the-fly php code
(and jsp, perl cgi, asp, etc).

Programatic page generation is transparently useful.
But querying a database, negotiatinig lots of if-then-else logic
and echo'ing html code out on port 80 every time a
page is requested has to be a huge waste of resources.

Why not use that logic to print static html instead of dynamic?
The few pages that need to be dynamic (perhaps the results of a
database
query) probably represent only a small fraction of the total
number of pages that are rendered by on the fly code.

Seems to make sense to me. All you need to do is work
the output directories into your code logic somehow,
and do a few one-time-only mkdirs before printing out the static html.

Am I missing something?
Why is it so little open source page generation software acually
works that way?

If I recall correctly, Smarty does something similar with it's caching.
Once a page is generated, it can be cached for a period of time so
that subsequent requests don't load the acutal page, but a static
version.

I see what you're trying to say, but don't agree with your assertion
that only a small fraction of pages need to be truly dynamic. Sure,
things like blogs or community webpages (or any page that only gets
updated once per day or slower) could benefit from serving static pages
and regenerating them at periodic intervals, but many web apps *need*
to be dynamically served at each page request. 90% of the pages in the
app I develop for need to show up-to-the-minute information from when
the page loads.

I haven't done the performance tests to see how serving up a cached
Smarty page vs a dynamically generated page compares, but I would guess
that the benefits are trivial to most people. If you're dealing with
traffic on the yahoo/ebay/google scale, then maybe that tiny boost
could mean hundreds of thousands of dollars in savings, but for most
people I don't think it really matters that much.

[Snef]

pittendrigh wrote:

There must be millions of dynamically generated
html pages out there now, built by on-the-fly php code
(and jsp, perl cgi, asp, etc).

Programatic page generation is transparently useful.
But querying a database, negotiatinig lots of if-then-else logic
and echo'ing html code out on port 80 every time a
page is requested has to be a huge waste of resources.

Why not use that logic to print static html instead of dynamic?
The few pages that need to be dynamic (perhaps the results of a
database
query) probably represent only a small fraction of the total
number of pages that are rendered by on the fly code.

Seems to make sense to me. All you need to do is work
the output directories into your code logic somehow,
and do a few one-time-only mkdirs before printing out the static html.

Am I missing something?
Why is it so little open source page generation software acually
works that way?

Hi,

I made a CMS that will create some 'static' html files on the server. When the
page changes, the page is generated again and written to the server again. This
way I save a lot of db queries and resources.

When the page needs something dynamic (like scheduled newsitems) it is fetched
through AJAX or (users choice) a 'more-dynamic' page (php and in the future also
in Perl or ASP) is generated.

The reason I choose this method had to do with the fact that the user of the CMS
should be able to easily link to a generated page. For most of the people it is
easier to search for somthing linke http://mydomain.com/aboutus.htm than
http://mydomain.com/index.php?page=aboutus or something similiar.

It works for my project...

Snef

[Rik]

Snef wrote:

pittendrigh wrote:

>There must be millions of dynamically generated
html pages out there now, built by on-the-fly php code
(and jsp, perl cgi, asp, etc).

Programatic page generation is transparently useful.
But querying a database, negotiatinig lots of if-then-else logic
and echo'ing html code out on port 80 every time a
page is requested has to be a huge waste of resources.

Why not use that logic to print static html instead of dynamic?
The few pages that need to be dynamic (perhaps the results of a
database
query) probably represent only a small fraction of the total
number of pages that are rendered by on the fly code.

Seems to make sense to me. All you need to do is work
the output directories into your code logic somehow,
and do a few one-time-only mkdirs before printing out the static
html.

Am I missing something?
Why is it so little open source page generation software acually
works that way?

Hi,

I made a CMS that will create some 'static' html files on the server.
When the page changes, the page is generated again and written to the
server again. This way I save a lot of db queries and resources.

When the page needs something dynamic (like scheduled newsitems) it
is fetched through AJAX or (users choice) a 'more-dynamic' page (php
and in the future also in Perl or ASP) is generated.

The reason I choose this method had to do with the fact that the user
of the CMS should be able to easily link to a generated page. For
most of the people it is easier to search for somthing linke
http://mydomain.com/aboutus.htm than
http://mydomain.com/index.php?page=aboutus or something similiar.

There are many reasons to use static pages, but this is not one of them.
Using .htaccess or similar, you can fetch requests easily. I usually use a
hierarchical tree for pages, like directories, so:
http://www.example.com/page1/sub3/ etc...

These directories do not exist, but route to the same php file, which
serves up the pages (be they database driven or included html-files, logs
specific requests for the stats, and performs any other actions required by
that page.

Static pages can be good for sites that don't change that often, with
little to no interaction, but readable urls is not a reason for it.

The way Moot mentions, creating html-files on the fly on changes, and serve
them up, is a method I've used often, no sense in keep generating the
pages. But they'll route through the php, which will check wether it's a
dynamic/user-interaction page or not, and on that basis will serve the html
file or build the page (and log traffic, specific requests, referrers etc).

Added bonus is that when a database is stretched for resources or
unavailable, a lot can be served, and you can even tell the users to come
back later on the dynamic pages when the database is unavailable. It
shouldn't be offcourse, but the safer the better :-).

Grtz,
--
Rik Wasmus

[Snef]

Rik wrote:

Snef wrote:

>pittendrigh wrote:

>>There must be millions of dynamically generated
html pages out there now, built by on-the-fly php code
(and jsp, perl cgi, asp, etc).

Programatic page generation is transparently useful.
But querying a database, negotiatinig lots of if-then-else logic
and echo'ing html code out on port 80 every time a
page is requested has to be a huge waste of resources.

Why not use that logic to print static html instead of dynamic?
The few pages that need to be dynamic (perhaps the results of a
database
query) probably represent only a small fraction of the total
number of pages that are rendered by on the fly code.

Seems to make sense to me. All you need to do is work
the output directories into your code logic somehow,
and do a few one-time-only mkdirs before printing out the static
html.

Am I missing something?
Why is it so little open source page generation software acually
works that way?

Hi,

I made a CMS that will create some 'static' html files on the server.
When the page changes, the page is generated again and written to the
server again. This way I save a lot of db queries and resources.

When the page needs something dynamic (like scheduled newsitems) it
is fetched through AJAX or (users choice) a 'more-dynamic' page (php
and in the future also in Perl or ASP) is generated.

The reason I choose this method had to do with the fact that the user
of the CMS should be able to easily link to a generated page. For
most of the people it is easier to search for somthing linke
http://mydomain.com/aboutus.htm than
http://mydomain.com/index.php?page=aboutus or something similiar.

There are many reasons to use static pages, but this is not one of them.
Using .htaccess or similar, you can fetch requests easily. I usually use a
hierarchical tree for pages, like directories, so:
http://www.example.com/page1/sub3/ etc...

These directories do not exist, but route to the same php file, which
serves up the pages (be they database driven or included html-files, logs
specific requests for the stats, and performs any other actions required by
that page.

Static pages can be good for sites that don't change that often, with
little to no interaction, but readable urls is not a reason for it.

The way Moot mentions, creating html-files on the fly on changes, and serve
them up, is a method I've used often, no sense in keep generating the
pages. But they'll route through the php, which will check wether it's a
dynamic/user-interaction page or not, and on that basis will serve the html
file or build the page (and log traffic, specific requests, referrers etc).

Added bonus is that when a database is stretched for resources or
unavailable, a lot can be served, and you can even tell the users to come
back later on the dynamic pages when the database is unavailable. It
shouldn't be offcourse, but the safer the better :-).

Grtz,

Rik,

Don't understand me wrong... my story didn't come out that well i think. I want
the pages to be generated for the customer so that they can easily look them up
in a editor (link FCKEditor). They just go to the directory where the file is an
select it to create a link. That is the easiest way for customers (for this
project). So the coice to use generated 'static' files is not just to create
those urls! I know i can use .htaccess to create friendly urls (if I had apache,
but I don't).

The main reason was to lower the use of database requests and other resources.
And for my project I needed those URL's but that was not the reason to do it
this way! :)

Snef.