If all the queries required in each php script on a web site are optimized best, which is the optimal concurrent mysql connections in busy state?

If single query is optimized well, it takes only 0.005 seconds or so.

If so 100 concurrent mysql connections per second can handle 20000 queries per second.

Front end queries does not include complex group by or extra file sorting at all.

Of course, the optimal concurrent mysql connections may be dependent on the available RAM and speed of disks.

I just want to know overall number to predict when we should separate master db server into several ones.

I found the problem of slow down of our site with small load of db server, web server thanks to this article.

Timeout setting in httpd.conf do great harm to so many mysql connections in sleep state for so long time(wait_timeout).

Original timeout was set to default (300 seconds). Some terribly slow http connection consumes timeout limit to get served from our web server, so there are many child processes even if actual traffic is not overloaded.

So mysql connection opened in slow HTTP connection reaches to wait_timeout and MySQL aborts those mysql connections.

There were about 200 Aborted_Clients per hour in mysql error log.

After changing Timeout directive in httpd.conf, all seems to be ok.

Mysql connections in sleep state only are available for short duration and there are no aboted_clients in mysql error log.

Opening site is so fast.

I have some relationship with chief architect of naver (no1. korean search portal).

Naver guru explained to me that the main bottleneck of web server only serving php scripts is CPU not RAM.

Modern best dual CPUs can handle at most 200 concurrent apache child processes, so Naver prepare to add new php dedicated web server when concurrent apache connection reaches to 100 at peak time.

Their daily page views handled by single php web server is 2 million or so.

So I think 100 concurrent apache child processes in well arranged server architecture( separation role to multiple servers like separation static file server, db server with highly optimized query and schema ) may be more optimal.

Anyway, thanks for your great articles.

I am always taking benefit from your articles.

I had no experiece at web developement 1 year ago, however, I am struggling to make scalable and stable large web site( no. 1 social networking site in China). In China, it is really hard to find guru on mysql, optimization because there are so many web sites cheating traffic.

Many Chinese web sites does not have real traffic, only cheating alexa traffic and do evil.
So there are small guru on optimization, scalability..

This is extra worse when you read the PHP docs and believe you’re better without output buffering. Then you start a transaction, emit some HTML, and the PHP page stays there waiting for the client to receive the data and sitting on its transaction locks.

The top on my list, is RAM, using the right MPM, configuring the MPM for your situation, setting KeepAlive to 2 seconds, and separating servers for static and dynamic content by either using Tux or Lighttpd.

Usually, the biggest issue is the default MPM settings, which are almost always set too high. You want the server to utilize all available resources, and not crash the system or make it unresponsive.

using light frontend for serving static content and buffering dynamic content is a must for a big project. otherwise your server is getting too vulnerable to simple attacks – just open 255 connections, send first line of the request (to overcome accept filters), and saturate all slots. light frontends have no trouble keeping tens of thousands connections open.

I already wrote about it in the article I mention at the start of this article. Yes quite frequently simply putting something in front is great idea. I use lighttpd in many cases – it works well and extremely easy to configure as proxy.

There are some things I do not like in lighttpd running in such mode. The main problem it buffers data fully before sending it back, meaning if you happen to have 1GB file downloaded it will allocate 1GB of RAM for the purpose. The other one is not using keep-alive for talking to the server which means a bit lower performance and it also means you can run out of local sockets in case of very high load.