By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,130 Members | 2,141 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,130 IT Pros & Developers. It's quick & easy.

MySQL Throughput??

P: n/a
JP
My company is considering acquisition of a packaged application that's based
on My SQL. This would be our first use of MySQL and the CEO is worried
about using a "no-name" database (he's a Microsoft bigot).

His specific concern is that an app written on MySQL will not have the
necessary throughput and he's asked me to research MySQL's capabilities.
From everything I've read so far, I'm comfortable that throughput will not
be a problem for this application under MySQL, but I thought it would be
useful to ask on a forum like this.

The application is client-server. From what I've been able to determine,
it's well-behaved client-server (really minimizes the dataflow back and
forth across the network). There will be about 600 users and we can expect
a peak usage of about 3 or 4 application transactions per user per hour (say
about 2400 application transactions per hour). I estimate that each
application transaction will require about 12 accesses to the database (say
3 inserts, 3 updates, and 6 selects), for a total of about 28,000-30,000 db
accesses per hour. In general, the selects will be returning small numbers
of rows from tables that are properly indexed for the selects.

Given the above, and assuming that we properly size the server (we're
planning on a honking big Dell under Windows), does anybody see any warning
flags about MySQL with that kind of volume? And yes, unless there's an
absolute "no way Jose", it will be a Windows server).

Thanks.
Jul 23 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Shouldn't be a problem if properly sized, although you'll likely get
better performance under linux. It really depends on how large the
tables are, how many full-table scans are required for joins, and how
complex your joins are.

You'll want to add indexes, optimize things, perhaps denormalize, and
the other tricks of the trade. 30,000 hits/hour = about 8 hits/second.
That's alot of traffic, but mySQL has been rock solid in my
experience. mySQL is the old cheapskate programmer mentality where
every byte counts, no bloatware there. I suspect you will be pleasantly
surprised with its performance given an adequately sized server.

JP wrote:
My company is considering acquisition of a packaged application that's based
on My SQL. This would be our first use of MySQL and the CEO is worried
about using a "no-name" database (he's a Microsoft bigot).

His specific concern is that an app written on MySQL will not have the
necessary throughput and he's asked me to research MySQL's capabilities.
From everything I've read so far, I'm comfortable that throughput will not
be a problem for this application under MySQL, but I thought it would be
useful to ask on a forum like this.

The application is client-server. From what I've been able to determine,
it's well-behaved client-server (really minimizes the dataflow back and
forth across the network). There will be about 600 users and we can expect
a peak usage of about 3 or 4 application transactions per user per hour (say
about 2400 application transactions per hour). I estimate that each
application transaction will require about 12 accesses to the database (say
3 inserts, 3 updates, and 6 selects), for a total of about 28,000-30,000 db
accesses per hour. In general, the selects will be returning small numbers
of rows from tables that are properly indexed for the selects.

Given the above, and assuming that we properly size the server (we're
planning on a honking big Dell under Windows), does anybody see any warning
flags about MySQL with that kind of volume? And yes, unless there's an
absolute "no way Jose", it will be a Windows server).

Thanks.

Jul 23 '05 #2

P: n/a
Here's some benchmarks - but certain it doesn't address your client/server
issues what so ever:
http://ftp.iranscience.net/pub/datab...enchmarks.html

I don't see any issue about that many transactions in mySql - if
1. if you have a properly configured and tuned server
2. if you tell your client/server developers (in house) that they ain't
gonna use stored procedures.
3. IF your vendor actually optimized the database with indices and primary
keys.
4. IF you segment your server backplane [4 or more ethernet cards] and use
high speed switches.
5. IF you make a backup ELSEWHERE [try that 5th ethernet card going to the
test server] that has
the data that the report designers will use.

let me know how it works out ?
and - whats the front end written in ?

mondo regards [Bill]
--
William Sanders / Electronic Filing Group Remove the DOT BOB to reply via
email.
Mondo Cool TeleCom -> http://www.efgroup.net/efgcog.html
Mondo Cool WebHosting -> http://www.efgroup.net/efglunar.html
Mondo Cool Satellites -> http://www.efgroup.net/sat
VFP Webhosting? You BET! -> http://efgroup.net/vfpwebhosting
mySql / VFP / MS-SQL

"JP" <jn************@optnospamonline.net> wrote in message
news:4n*****************@fe08.lga...
My company is considering acquisition of a packaged application that's based on My SQL. This would be our first use of MySQL and the CEO is worried
about using a "no-name" database (he's a Microsoft bigot).

His specific concern is that an app written on MySQL will not have the
necessary throughput and he's asked me to research MySQL's capabilities.
From everything I've read so far, I'm comfortable that throughput will not
be a problem for this application under MySQL, but I thought it would be
useful to ask on a forum like this.

The application is client-server. From what I've been able to determine,
it's well-behaved client-server (really minimizes the dataflow back and
forth across the network). There will be about 600 users and we can expect a peak usage of about 3 or 4 application transactions per user per hour (say about 2400 application transactions per hour). I estimate that each
application transaction will require about 12 accesses to the database (say 3 inserts, 3 updates, and 6 selects), for a total of about 28,000-30,000 db accesses per hour. In general, the selects will be returning small numbers of rows from tables that are properly indexed for the selects.

Given the above, and assuming that we properly size the server (we're
planning on a honking big Dell under Windows), does anybody see any warning flags about MySQL with that kind of volume? And yes, unless there's an
absolute "no way Jose", it will be a Windows server).

Thanks.

Jul 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.