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=storytopic=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
