Server Databases Clash

Started by Michael Tiemannalmost 24 years ago3 messages
#1Michael Tiemann
tiemann@redhat.com

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&amp;a=23115,00.asp&gt;

#2Vince Vielhaber
vev@michvhf.com
In reply to: Michael Tiemann (#1)
Re: 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&amp;a=23115,00.asp&gt;

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
==========================================================================

#3Rod Taylor
rbt@zort.ca
In reply to: Michael Tiemann (#1)
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.