One thing about the pooling, persistent connections is that if you create temporary tables you need to drop them before you leave, or they just might be hanging around and if you have routines that create them, they could/will be there, because the session is still active.
At least I think that is the correct wording. I ran into this problem before, I was lazy and didn't drop the temporary table, and when I tried to create it, it already existed. Kelley Dan Greene wrote: > 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] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
