Concurrent page request comparisons

Question

I have been hoping to find out what different server setups equate to in theory for concurrent page requests, and the answer always seems to be soaked in voodoo and sorcery. What is the approximation of max concurrent page requests for the following setups?

apache+php+mysql(1 server)

apache+php+mysql+caching(like memcached or similiar (still one server))

apache+php+mysql+caching+dedicated Database Server (2 servers)

apache+php+mysql+caching+dedicatedDB+loadbalancing(multi webserver/single dbserver)

apache+php+mysql+caching+dedicatedDB+loadbalancing(multi webserver/multi dbserver)

+distributed (amazon cloud elastic) -- I know this one is "as much as you can afford" but it would be nice to know when to move to it.

I appreciate any constructive criticism, I am just trying to figure out when its time to move from one implementation to the next, because they each come with their own implementation feat either programming wise or setup wise.

Answer 1

In your question you talk about caching and this is probably one of the most important factors in a web architecture r.e performance and capacity.

Memcache is useful, but actually, before that, you should be ensuring proper HTTP cache directives on your server responses. This does 2 things; it reduces the number of requests and speeds up server response times (if you have Apache configured correctly). This can also be improved by using an HTTP accelerator like Varnish and a CDN.

Another factor to consider is whether your system is stateless. By stateless, it usually means that it doesn't store sessions on the server and reference them with every request. A good systems architecture relies on state as little as possible. The less state the more horizontally scalable a system. Most people introduce state when confronted with issues of personalisation - i.e serving up different content for different users. In such cases you should first investigate using the HTML5 session storage (i.e store the complete user data in javascript on the client, obviously over https) or if the data set is smaller, secure javascript cookies. That way you can still serve up cached resources and then personalise with javascript on the client.

Finally, your stack includes a database tier, another potential bottleneck for performance and capacity. If you are only reading data from the system then again it should be quite easy to horizontally scale. If there are reads and writes, its typically better to separate the read write datasets into a separate database and have the read only in another. You can then use more relevant methods to scale.

Answer 2

These setups do not spit out a single answer that you can then compare to each other. The answer will vary on way more factors than you have listed.

Even if they did spit out a single answer, then it is just one metric out of dozens. What makes this the most important metric?

Even worse, each of these alternatives is not free. There is engineering effort and maintenance overhead in each of these. Which could not be analysed without understanding your organisation, your app and your cost/revenue structures.

Options like AWS not only involve development effort but may "lock you in" to a solution so you also need to be aware of that.

I know this response is not complete, but I am pointing out that this question touches on a large complicated area that cannot be reduced to a single metric.

I suspect you are approaching this from exactly the wrong end. Do not go looking for technologies and then figure out how to use them. Instead profile your app (measure, measure, measure), figure out the actual problem you are having, and then solve that problem and that problem only.

If you understand the problem and you understand the technology options then you should have an answer.

If you have already done this and the problem is concurrent page requests then I apologise in advance, but I suspect not.