I'm confused about concurrent MySQL connections

So, I read a book in Mysql and it says that there's a limit on how many concurrent users that can access a database.

Does that mean that If I have 20k users browsing in my开发者_开发百科 web application concurrently, my web application will fail to load the data in my database? Because my web application is accessing the database every time my website loads.

20k users loading a page at the exact same time ? That's quite a lot -- and your webserver will probably not accept that many concurrent requests itself (For example, Apache generally accepts only between 200 and 400 parallel requests).

The connection limit is the maximum number of users that can be connecter to your database at the exact same time -- if each page needs 100 ms to be generated, one user will only be connected for less than 100 ms.
And if you connect to your database just when you need to do your first SQL query, and disconnect immediately after your last SQL query, this can reduce the time during which your Webserver is connected to the DB.

If you have users reading content from your website, you can consider they will :

• Load a page (maybe 100 ms on your server)
• Do nothing but read for a couple of minutes (which takes absolutly no resource on your server)

As a sidenote : quite a long time before getting 20k concurrent connections (which means about 20,000 connections per second or so !), you'll probably have to deal with several scaling-relating problems...

If you get a Too many connections error when you try to connect to the mysqld server, this means that all available connections are in use by other clients.

The number of connections permitted is controlled by the max_connections system variable. Its default value is 100. If you need to support more connections, you should set a larger value for this variable.

You should ask your system administrators to do these changes only when necessary.

For me I think at least it is impossible since the execution/processing time are counting in Milli seconds

after reading i found this snippet

20.000 concurrent users is 20.000 CONCURRENT DATABASE QUERIES... a user reading a post in your site, should not be counted in the concurrent user number... he is logged in to your site, but he is not requiring anything from the database... now, if he clicks in a link, the database will perform a query and, then, this user should be counted in the concurrent users number... only if 20.000 users click somewhere on your site AT THE SAME TIME you will have 20.000 concurrent users

Database is very good candidate for bottle neck. If you have so big traffic on your server you should focus on downgrade number of connections to the database. Page and Data Caching can do miracle in this matter - it did in my case....

Assuming you have a standard web application architecture, with a database at the back and the web server(s) getting data from the database, then each instance of the web server would generally be a single database user.

From your application's standpoint, each remote user is a user, but from the database's standpoint your application is a single user.

From the web server's standpoint, the important performance number is the number of operations per second it is being asked to do. For example, if you have a blog web site, so users will typically read for a minute between clicks, then 10,000 active users might generate a request rate of 10,000 / 60 = 166 requests per second, which would generally be well within Apache's capabilities. (You have to consider the performance mix of your application from your web server's standpoint: CPU time, network bandwidth, disk bandwidth, memory consumption, ... to get the more complete and accurate picture of how well a web application may scale within a single web server.)

If you have enough load so that you need multiple web servers with e.g. a load balancer in front, then each web server would be a database user. If you have scaled to the point where you need 10,000 web servers to service your customer base, you would generally have had to resort to other technologies to solve other database performance scaling problems anyway.