David A. Wheeler wrote:
Unfortunately, we can't really separate processor architecture from
software architecture - the goal is to maximize performance while
minimizing hardware & development-time cost. Hopefully, this
kind of free-flowing discussion of alternatives will yield
that perfect combination - or at least a good one.
I think the three critical resources at the moment are:
* disk head contention on the DB
* lock contention / concurrency control on the DB
* memory on the DB (memory is > 1000 times faster than disk)
The solutions for these are:
* Disk head contention: add more, faster disks, in a RAID
* Careful database design / shifting to a DB which handles concurrency
better (PostgreSQL?)
* Slamming in as much RAM as possible on the DB machine
Query processing, on the other hand, is easily parallelizable by adding
multiple cheap front-end boxes, and load-balancing via round-robin DNS
or some other scheme.
However, all this is based on thinking rather than measurement, and
test-and-measure is the only way forward.
This is where splitting the DB from the page rendering is vital: it will
allow these two to be individually measured, to see where resources are
really being used.
Neil