At 06:16 PM 11/13/00 +0100, fabrizio.ermini@sysdat.it wrote:
>> Still...Regardless of what database they're running, either their
>> abstraction layer is shit or their queries really need optimized. Is that
>> perhaps why, even at 5 clients, the page views he shows never went
>> significantly above 10/sec?
>>
>I think this could be because they used real killer pages in the test,
>and maybe this also the reason PgSQL fared this good (I've always
>been and I'm still a postgres fan, but looking at that results I've
>been quite astonished!!). Have you looked the spec? If I remember
>well, Tim was talking about executing cuncurrently a page that
>joined a dozen tables and another that was doing
>update/select/insert on the same tables. Under these condition, 10
>pages/sec it seems lighting to me!!!!
But much of this could still be cached. I visit my homepage at sourceforge
rarely, because my project uses sourceforge for its cvs repository, only.
So all those joins are mostly a waste. I never have new postings in my
project forums, blah blah. Some level of caching could help (not for me
personally, I visit too rarely for a system to want to cache my query
returns involved in building my home page, but I'm sure there are many
cases where caching would help).
Again, you have to balance query cache RAM consumption against the benefits
of extra RAM availability to the RDBMS (assuming you have one, which
MySQL isn't :)
- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.