On Sat, 2 Sep 2006, M. Edward (Ed) Borasky wrote:

> 5. Database "bottlenecks": Most of the "industrial strength" databases
> -- Oracle, PostgreSQL, MySQL, SQL Server 2005, DB2, etc. -- are
> co-optimized with the operating systems and the platform hardware.
> They've done their homework; they've done their performance engineering,
> profiling and micro-benchmarking.
>
> As good as they are, a poorly engineered database schema can make the
> RDBMS work much harder than it needs to, requiring more hardware than is
> necessary.

It is very easy, though, for even simple queries on a simple, optimized 
DB schema on a well tuned engine to be the single largest bottleneck for a 
dynamic web site or web based application.

Take, for example, a site that I am working on today.

It is dynamically generated using data from a simple db, but it is ok for 
there to be a short latency between changes to db data and changes 
appearing on the site pages.

Querying everything from the db for every request was netting around 35 
pages per second -- a little under 3 hundredths of a second per page 
generation.  Changing the code so that it queries no more than twice a 
minute, operating off of cached data between queries, dropped the page 
generation to around 5 or 6 thousandths of a second -- about 170ish a 
second.  For comparison, on my development server I get about 620 page 
loads a second from a static version of the content.

The database presents a significant bottleneck that I can fortunately work 
around through a little bit of caching.  If, for whatever reason, I could 
not employ this caching, that db bottleneck could be a much more 
significant issue than any Ruby speed issues.


Kirk Haines


BTW, just for comparison, a version of this content rendered and delivered 
through CakePHP on PHP4, with no db data caching, renders about 17 pages 
per second.