At 11:22 AM 11/13/00 -0500, Robert D. Nelson 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?
They don't appear to do any client-side query caching, which is understandable
from one point of view (you need some sort of handle on which queries are
hit frequently enough to warrant devoting RAM to caching the result, or else
you risk caching things that don't gain you much and cut down on the amount
of the DB cached in RAM which hits you on other queries). On the other hand,
you'd think they'd do some analysis...
Still, the table-locking of MySQL just gets in the way. If you can cache
everything, then you can send a postal worker to the mailbox to retrieve
uncached data without significantly impacting throughput (in other words,
the MySQL argument that simple select benchmarks are all you need are
not relevant). If you can't cache anything but have few users, then perhaps
low levels of concurrency don't hurt. If you don't cache anything but have
lots of users, scaling well under high levels of load rule.
My thinking is that intellegent caching coupled with a highly-scalable
database wins. That's the world I'm used to...
- 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.
