up vote -6 down vote favorite
share [g+] share [fb]

Let's say I have a dedicated server with only 1 website in it (LAMP)
Let's say 4 GB RAM and an average CPU dual core @ 2.5GHz with Debian

Let's say the php pages doesn't require much CPU load, they can load up in few istants (0,01 sec)

How many concurrent users/pages this server can handle?

link|improve this question
78% accept rate
Run a test, and you will find out. – Zoredache Jan 29 at 21:46
I don't think i can run a test on my server, and I don't have the same machine in locale – yes123 Jan 29 at 21:47
There are many many factors that need to be taken into account here, and it's impossible to run through them all. If you can't test your app, you'll want to try to at least profile it once it's live so that you can project what load it can handle, and identify the bottlenecks. – James Polley Jan 29 at 21:56
feedback

closed as not a real question by SvenW, Shane Madden, Zoredache, ErikA, joeqwerty Jan 29 at 23:29

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. See the FAQ for guidance on how to improve it.

1 Answer

up vote 2 down vote accepted

There is no specific answer, and you have to benchmark a realistic load to know.

Since you gave a number, though, that is pretty simple: you have two cores, and can deliver a PHP response in 0,01 seconds, so the math is:

2 (cores) * 1 (second) / 0,01 (seconds per response) = 200 pages per second.

You can then work out the longest response time you are willing to tolerate for a user, and the overhead for static assets, and do some math to work out a final number.

You can probably guestimate about 75 percent of that number as real user interaction for a simple site, or 50 percent for an AJAX heavy one, so between 100 and 150 users, more or less.

Don't forget to tune Apache to that load, and to make sure you have enough memory to serve it, though.

link|improve this answer
100 users per second * 86400 secs = 8 millions of pageviews/day with that server. I don't think apache2 can handle that considering MPM prefork – yes123 Jan 29 at 21:50
Of course there are other factors that are going to affect the real answer - for instance, if the code has to get a database lock before it can render the page, you're going to have more contention issues as the number of pages rendered per second increases, and you won't get linear scaling. At some point you'll start running out of RAM or network bandwidth... But this is a good start, and about as good as you're going to get without being able to test and profile the application – James Polley Jan 29 at 21:54
Assuming that the cited 0,01 seconds per response is accurate, it can. Is the number the OP supplied accurate? I would be pretty surprised, but you never know. This could be the one good bit of PHP software out there. There is no reason that prefork Apache can't keep up with that rate - absent the memory consumption of 100 concurrent children, as per my final line. :) – Daniel Pittman Jan 29 at 21:56
1  
@yes123 - not even close to stressing out the system, no. The C10K problem was a headache some years back, for Linux - how to serve 10,000 concurrent connections. Now, effort is invested in the C100K problem - how to handle 100,000 concurrent connections on a single machine. (...though, as with everything performance-wise, it depends on the workload. 100 hits all reading from slow SATA disk? Might struggly. 100 hits all from RAM? trivial.) – Daniel Pittman Jan 29 at 22:01
1  
@yes123 - not really, no. Performance always comes down to which resource you run out of first: CPU, RAM, network bandwidth, network latency, disk IOPS, disk bandwidth. Something always runs out first, and limits your performance. Fix that, and another will run out, limiting your performance... – Daniel Pittman Jan 29 at 22:43
show 2 more comments
feedback

Not the answer you're looking for? Browse other questions tagged or ask your own question.