3

Do we get efficiency in terms of load handling when the same container (in this case the container has a apache server and a php application) is deployed 5 or more times (i.e. 5 or more containers are deployed) on the same Host or VM?

Here efficiency would mean whether the application is such architecture is able to serve more requests or serve requests faster?

As far as i am aware, each request launches a new apache-php thread and if we have 5 containers handling the requests then will it be inefficient since now the threads launched by apache will be contextually be switched out more often?

1

This is a good question but not a simple one to answer purely in theory. A lot of the answer hinges on how isolated the threads are in the Apache/PHP architecture. While there may be separate threads, that doesn't mean there is no contention between them. For example, they may lock on shared mutexes or semaphores. In that case having 5 containers executing 1 request each maybe able to handle more concurrency than 5 threads in one application instance.

As far as whether there will be more thread context switching. That isn't necessarily the case given the same number of requests. However, if there is one or more non-request thread per instance, you would have 5 times the number of these overhead threads.

I suggest trying various configurations under load and get metrics for better understanding of the costs and benefits of each.

There are other benefits to isolation though that may outweigh such costs if they exist. One major benefit is that if you have one container crash from a bad request, you will not lose the other 4 and a lot of tooling allows to automated restoration of downed containers. Also if you are subject to any of the many vulnerabilities that are regularly found in PHP packages, an attacker will have to escape from the container in order to gain access to or control over the host/VM.

  • The same advantages you list for containers basically also exist for Apache worker processes. There are multiple of them in order to service concurrent requests. If one crashes, Apache can spawn another one. They are often run under a special www user with few privileges, so an attacker would somehow have to escape from that first. There's a reason for these similarities: containers are just ordinary processes with extra sandboxing features tacked on, e.g. network namespaces (so each Apache container can think it actually runs on port 80). – amon Jun 1 '18 at 21:06
  • @amon "There are multiple of them in order to service concurrent requests. If one crashes, Apache can spawn another one." Sure but not if it crashes the entire process, right? – JimmyJames Jun 4 '18 at 13:30
  • @amon "They are often run under a special www user with few privileges, so an attacker would somehow have to escape from that first." and if you are running Apache in a container, you still have to do that. If you succeeded you then also have to escape from the container. – JimmyJames Jun 4 '18 at 13:32
1

No it is generally* not more efficient to run multiple containers on a single host running the same application.

Even if we assume no overhead for running containers, web servers are already designed to handle as many requests as possible.

If handling more requests was as simple as running the program twice (which in effect it is) then they would already do that (which in effect they do)

*Perhaps if you had a program which wasn't designed for the task, say using Excel to process business rules for example, you would want to have a multiple containers strategy to get around its limitations, eg having multiple copies open at the same time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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