Speeding with Static Pages
We hate to wait. Every second that we wait for a Web page or document
to open feels like an eternity. This is especially true for a corporate
intranet, where workers want to find their document or complete
their request without delay and get back to their real work. This
poses a dilemma for a database-driven intranet because every database
connection slows down the transaction, no matter how well the process
need for speed
We were disappointed when the first iteration of our new intranet,
with dynamically generated pages, wasn't quite as quick as we preferred.
It wasn't bad, but we wanted it to be faster. Joe suggested that
we create a hybrid process that leveraged the flexibility of the
database design with the speed of static pages.
created an automated process to sweep through the Backbone database
(Driving With Databases)
and create every navigation page that is defined in the database.
Each generated page is saved in the appropriate folder as a static
HTML page, eliminating the need for that page to touch the database
when it is opened by a user.
The automated "genBackbone" process runs every 30 minutes,
with a manual override available if we need to regenerate the site
before the next scheduled update. This process currently generates
about 735 pages, and takes about five minutes to complete.
course, this only affects the navigation pages for the intranet.
These pages contain all the links to lower-level categories or to
specific documents, as defined in the Backbone database. Pages or
documents with actual content are updated manually, and are not
touched by the genBackbone process.
pages dynamically from a database will always take longer, and
should be reserved for situations where it is really necessary.
a little creativity, it is possible to have the best of both worlds
storing the site structure in a database without touching
the database during routine use.
Posted 31 March 2008