Thread: Server Databases Clash
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>
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 atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> 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.