Here's an excerpt from a database comparison between Oracle, DB2, MySQL, 
SQLserver, and Sybase.  (I just asked the author why postgres wasn't used.)

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.

<http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp>


Fri, 01 Mar 2002 07:44:30 -0500
Michael Tiemann <tiemann@redhat.com>
Server Databases Clash
On Fri, 1 Mar 2002, Michael Tiemann wrote:

> Here's an excerpt from a database comparison between Oracle, DB2, MySQL,
> SQLserver, and Sybase.  (I just asked the author why postgres wasn't used.)
>
> 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.
>
> <http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp>

If the use of a database on a webserver is to keep serving up the same
data over and over again that the database caches it, why not just serve
up a static page?  You can keep the content of an entire website in a
database and generate static pages as the content changes.  The PostgreSQL
website does this.  The only exception being the iDocs, but that's not
hit enough to worry about with caching or making some of the pages static.

I have a number of webservers that are database driven and I'd be
surprized if any of them saw the same queries even twice in the same day.
Anything I know that will get requested that often will be made static -
and since I designed the site, I know what's going to be requested
repeatedly.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
         56K Nationwide Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Fri, 1 Mar 2002 08:40:36 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: Server Databases Clash
> 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.


Fri, 1 Mar 2002 08:42:24 -0500
"Rod Taylor" <rbt@zort.ca>
Re: Server Databases Clash