MySQL Throughput??

[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.

[Paul Bramscher]

Re: MySQL Throughput??

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:[color=blue]
> 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.
>
>[/color]

[swdev2]

Re: MySQL Throughput??

Here's some benchmarks - but certain it doesn't address your client/server
issues what so ever:

http://ftp.iranscience.net/pub/databases/mysql/information/benchmarks.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" <jnospamperelst @optnospamonlin e.net> wrote in message
news:4nzJd.1151 $MK2.1086@fe08. lga...[color=blue]
> My company is considering acquisition of a packaged application that's[/color]
based[color=blue]
> 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[/color]
expect[color=blue]
> a peak usage of about 3 or 4 application transactions per user per hour[/color]
(say[color=blue]
> about 2400 application transactions per hour). I estimate that each
> application transaction will require about 12 accesses to the database[/color]
(say[color=blue]
> 3 inserts, 3 updates, and 6 selects), for a total of about 28,000-30,000[/color]
db[color=blue]
> accesses per hour. In general, the selects will be returning small[/color]
numbers[color=blue]
> 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[/color]
warning[color=blue]
> 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.
>
>
>[/color]