Ahh... the proverbial 'how many licks does it take to core the database....'

There is no straightforward answer.  That's the bad news.
However, the basics are identical for all databases....

basically, though, 
the more memory you have, the more concurrent connections you can handle.
The more CPU power you have, the more complicated queries you can perform.
Extra memory, after covering maintaining your connections, goes to assisting query 
performance.

-- MOST IMPORTANT -- 
No amount of hardware can make up for crappy SQL.  I've seen single queries lock down 
an enterprise level Oracle database.  Always tune your queries for performance, and 
index your tables on frequently "where'ed" columns (primary keys, common lookups) 

Taking that, and realizing that in most applications with user interfaces, your 
connections are idle most of the time, connection pooling was created.

This way, you maintain a set number of connections (most systems allow flexibility, 
such as keep at least 5 connections open, and grow the pool as needed, up to 15 
connections).

You app server (tomcat, php, etc...), or connection manager (PoolMan), then maintains 
those connections, not your code directly.  You 'borrow' an existing idle connection, 
use it, and return it to the pool for another user/component to use.

With connection pooling, you 'virtual' number of connections skyrockets, without 
giving up more memory than needed, which will help query performance.

Hope this helps somewhat...


Last comment...

What do you mean by 'reasonable hardware'?  I think my old C-64 is reasonable hardware 
(heck... it ran a windows environment on 2 low-density floppys, no hard drive, and 64k 
of memory... ahhh  Geos....)

> -----Original Message-----
> From: William R. Mussatto [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 03, 2003 6:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: How much user LOAD can Mysql bear???
> 
> 
> Tariq Murtaza said:
> > Thanks Fortuno, Adam
> >
> > Actually, I was thinking about concurrent users that mysql 
> can handle,
> > provided with reasonable hardware.
> > Looking for comments / suggestions.
> >
> > Regards,
> >
> > Tariq
> >
> > Fortuno, Adam wrote:
> >
> >>Tariq,
> >>
> >>Check the list's history - this is actually a frequent question. The
> >> answer everyone is about to give you is generic. "MySQL's 
> ability is
> >> havily based on the hardware and OS it runs on. Therefore, a
> >> multi-processor machine with lots of memory can handle more than a
> >> single processor workstation with 256 MB of RAM. The 
> faster the machine
> >> the faster MySQL... etc."
> >>
> >>Be more specific, whats the hardware and software. How much 
> information
> >> are you storing in the DB? Any replication?
> >>
> >>Regards,
> >>Adam
> >>
> >>-----Original Message-----
> >>From: Tariq Murtaza [mailto:[EMAIL PROTECTED]
> >>Sent: Tuesday, September 02, 2003 8:40 AM
> >>To: [EMAIL PROTECTED]
> >>Subject: How much user LOAD can Mysql bear???
> >>
> >>
> >>Hi All!
> >>
> >>How much user LOAD can Mysql bear before die.
> >>
> >>Regards,
> >>
> >>Tariq
> You haven't changed the question. The number of concurrent 
> users is the
> same as the number of connections...if they are TRUELY 
> concurrent.  That
> is is they all hit the submit button at the same time.  You 
> set the number
> on connections.  Each connection takes up a bit of memory, 
> even if idle
> (php and mod_perl hold open connections.  .jsp may or may not.
> Your response time (how long is acceptable) will depend on you actual
> database and questions you ask it as well as the hardware.  
> It might help
> if you told us what hardware you are planning to use or what kinds of
> questions or environment it will support.  Then the list can get more
> specific.
> 
> William R. Mussatto, Senior Systems Engineer
> Ph. 909-920-9154 ext. 27
> FAX. 909-608-7061
> 
> 
> 
> -- 
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    
> http://lists.mysql.com/[EMAIL PROTECTED]
> 
> 

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to