Determining level of concurrency of your system will be highly dependent on size of the pages served and the connectivity of the remote clients accessing your site. Linux's performance handling of large numbers of simultaneous connections decays exponentionally. It's a kernel limitation in the way that polling is implemented. The limit tends to be around 3,000 active connections. Apparently, adapting your webserver to use E-Poll can increase this to about 10,000 active connections, but this can take some serious hackage.
You probably won't need to worry about that though, since the execution time of a single page will not be fast enough to reach the 3000 requests per second. And even if you did, your bandwidth is probably not able to deliver the content anyways. To add to the problem, often a fair share of your remote clients will be on slow/dirty links that leave lingering connections or take several seconds to download the response page. As a result, the number of open connections at any given time will be radically reduced. I'm going to go out on a limb and say that the limitations of your server will not be hardware but software/OS. To get a ball park figure of how many requests your system can handle in a perfect world, use the Apache Benchemark tool (man ab). What ever the number you get, expect it to be the upper limit of what your server can handle in a real-world scenario. Also, don't forget to consider the amount of bandwidth you have at hand. In the real world, a 100mbit card can only do b/w 70-80mbits. Optimization: Your best bet is looking into using reverse proxy solutions (Squid Accelerators) as a gateway to your PHP machine. Since the proxies quickly request the information (similar to the perfect world scenario), you leave the server open to more connections. Further more, the proxies are often more easily load balanced. If you use proxies, they will also cache the images on your website, leaving your PHP server free to process _only_ dynamic requests (very important). Further more, even certain 'dynamic' requests are cache-able for some amout of time if you appropriately use expiration headers. Also, cache/proxy servers are better suited to handle large numbers of simultaneous users. Using TUX on a separate machine to serve your images (or other STATIC content) is another nice way to free up the number of connections on the server. TUX will easily saturate a 100mbit pipe before you kill your box. Also, make sure you use persistent mysql connections in the PHP code and limit bump up the number of simultaneous connections MySQL can handle. The default number is very low. The number should be not less than the number of concurrent connections on the machine. Well, that's that... Hope your PHP code is well written. :) Erik Osterman http://osterman.com/ -----Original Message----- From: Boaz Yahav [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 12:55 PM To: [EMAIL PROTECTED] Subject: [PHP] (Semi OT) Number of concurent Users. Hi I was wondering if anyone has any idea about how many users the next configuration can hold : Front End ============= Dual Xeon 2.4Ghz Compaq DL360 G3 1GB of memory SQL Server ============= Compaq DL 380 G3 Dual Xeon 2.4Ghz 2GB Memory 15K disks (RAID 0+1) Site can be a content site like weberdev.com or a simple ecommerce site running on Linux / Apache / MySQL / PHP. Any idea how many concurrent users can run on such a configuration? Any idea how this number will grow using one of the performance suits for PHP on the market? Sincerely berber Visit http://www.weberdev.com/ & http://www.weberblog.com/ Today!!! To see where PHP might take you tomorrow. Share your code : http://addexample.weberdev.com Search for PHP Code from your browser http://toolbar.weberdev.com Share your thoughts : http://www.weberblog.com/submit.php?type=story&topic=PHP_Web_Logs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
