Brian Bray wrote:
> I know that asking how many queries per second mysql is capable of
> handling is a bad question but I really need a ballpark guestimate.
> I am trying to forcast my db server needs for the next year or two. I'm
> not worried about the web server end of things because web servers are
> easily scalable, db servers are not.
> Basically if I were to get a pretty hot machine (something like dual
> processors and 1/2 gig of ram) dedicated to mySQL I need to know about how
> many queries per second I could expect to get of it.
> The query breakdown would be something like this:
> 50% Simple SELECT (NO JOINS) returning 50-100 records each.
> 25% More complex SELECT queries (Containing Joins) usually returning a
> single row but sometimes more.
> 20% Updates
> 5% Other
> And lets say that the main tables being maipulated contain approxamately
> a million records each.
> As I said I know this is a bad question. Too many variables but I just
> want a ballpark (say 50 queries/sec 100 queries/sec or what?)
Here is how I would approach the problem. Maybe a litte
radical, but I like the so-called "radical" solutions.
First code up your application and make it work at half
way decent speed under load on something very modest,
like Pentuim 166. That will force you to write efficient
queries, optimize table design, clean up dirty loops in
your code, etc. When you think you are done,
artificially create a heavy load to see how many queries
per second your test machine could handle. While your
are hitting it, use top and other system monitoring
tools to see what resource is the bottleneck. Gradually
start upgrading bottleneck resources one by one ( since
when you upgrade one, the other may then be the
bottleneck) until you machine performs to your