> MySQL's great performance was due mostly to our use of an in-memory
query
> results cache that is new in MySQL 4.0.1. When we tested without
this cache,
> MySQL's performance fell by two-thirds.
>
> Anyway, this confirms an earlier message suggesting that for web
servers that
> have relatively constant queries, query caching can be a Big Deal.
I'd be willing to bet that they would have been around 15 to 20%
faster if their JSP code did the caching as there is no protocol or
transfer overhead.
For that matter, if they were to have used static webpages with no JSP
code (updating those as needed) they probably could have been several
orders of magnitude higher in their serving speed.
If the information in the database is truely that consistent, it makes
the most sense to go with the last option as you don't want the
overhead of PHP, JSP, ASP and friends either. Afterall, why waste all
that time generating the same HTML pages time and time again. The
problem really has nothing to do with the database. PHP may wish to
(and I think there is a project) add caching of a generated page for
common request variables to avoid generation of the page entirely.
High volume 'dynamic' websites often use this method when they expect
a low number of changes. Slashdot is a good example. Static
frontpage and main page of chat rooms, but once you go in a couple of
levels it's generated on the fly due to high level of change compared
to requests for the information.