My application is intended to be scalable. In the eyes of the marketing
departments, it should be scalable from zero to infinity. But we all know
that this is not possible indefinitely - at some point you reach a
bottleneck. In the case of my system, that bottleneck will eventually be
the MySQL write side. I can split the system load by having replicated
read-only slaves, but I must (as far as I can see) have a single update
point, which must then also act as replication master for the read slaves.
(I don't mind a second or two of latency in the propagation of updates from
the write side to the read side.)
The question is how far I can allow the marketing department to extrapolate
the performance of my current systems. Should we get the orders of which
they dream, the budget will be generous. So the question is, in a way, how
much faster I can get MySQL to go by throwing money at it.
I plan to load test the system on the hardware I have - dual 1.7GHz Xeon
running Win2K, 2Gb, 15000 rpm Scsi disk.
I imagine that the fastest hardware would be a big multi-cpu Sun server
with Raided disks. If I (or rather, my marketing department) went to Sun
with an open chequebook, how many times faster than my reference system
would it run?
You will understand that, in the absence of an order, the "built it and
try" approach doesn't appeal.
I realise that it is beyond the wit of any man to give an exact answer, but
I really need only an order-of-magnitude: 4 times? 25 times? 100 times? (I
doubt the last.) Something to choke off the marketing people when they get
to carried away - or to force them to think about different system
configurations that allow multiple databases.
Alec
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
