Why do we use multi application server instances on the same server

12,331

Solution 1

Hmmm... After a long time I am seeing this question again :)

Well a multiple JVM instances on a single machine solves a lot of issues. First of let us face this: Although JDK 1.7 is coming into picture, a lot of legacy application were developed using JDK 1.3 or 1.4 or 1.5. And still a major chunk of JDK is divided among them.

Now to your question:

Historically, there are three primary issues that system architects have addressed by deploying multiple JVMs on a single box:

  1. Garbage collection inefficiencies: As heap sizes grow, garbage collection cycles--especially for major collections--tended to introduce significant delays into processing, thanks to the single-threaded GC. Multiple JVMs combat this by allowing smaller heap sizes in general and enabling some measure of concurrency during GC cycles (e.g., with four nodes, when one goes into GC, you still have three others actively processing).

  2. Resource utilization: Older JVMs were unable to scale efficiently past four CPUs or so. The answer? Run a separate JVM for every 2 CPUs in the box (mileage may vary depending on the application, of course).

  3. 64-bit issues: Older JVMs were unable to allocate heap sizes beyond the 32-bit maximum. Again, multiple JVMs allow you to maximize your resource utilization.

  4. Availability: One final reason that people sometimes run multiple JVMs on a single box is for availability. While it's true that this practice doesn't address hardware failures, it does address a failure in a single instance of an application server.

Taken from ( http://www.theserverside.com/discussions/thread.tss?thread_id=20044 )

I have mostly seen weblogic. Here is a link for further reading:

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/WLSTuning.html#wp1104298

Hope this will help you.

Solution 2

I guess you are referring to application clustering.

AFAIK, JVM's spawned with really large heap size have issues when it comes to garbage collection though I'm sure by playing around with the GC algorithm and parameters you can bring down the damage to a minimum. Plus, clustered applications don't have a single point of failure. If one node goes down, the remaining nodes can keep servicing the clients. This is one of the reasons why "message based architectures" are a good fit for scalability. Each request is mapped to a message which can then be picked up by any node in a cluster.

Another point would be to service multiple requests simultaneously in case your application unfortunately uses synchronized keyword judiciously. We currently have a legacy application which has a lot of shared state (unfortunately) and hence concurrent request handling is done by spawning around 20 JVM processes with a central dispatching unit which does all the dispatching work. ;-)

Solution 3

I would suggest you use around least JVM per NUMA region. If a single JVM uses more than one NUMA region (often a single CPU) the performance can degrade significantly, due to a significant increase in the cost of accessing main memory of another CPU.

Additionally using multiple servers can allow you to

  • use different versions of java or your your applications server.
  • isolate different applications which could interfere (they shouldn't but they might)
  • limit GC pause times between services.

EDIT: It could be historical. There may have been any number of reasons to have separate JVMs in the past but since you don't know what they were, you don't know if they still apply and it may be simpler to leave things as they are.

Solution 4

An additional reason to use mutliple instance is serviceability.

For example if you multiple different applications for multiple customers then having seperate instances of the appserver for each application can make life a little easier when you have to do an appserver restart during a release.

Share:
12,331
Sebastien Lorber
Author by

Sebastien Lorber

React expert & early adopter (January 2014) Freelance, working for Facebook/Meta as Docusaurus maintainer since 2020. Author of ThisWeekInReact.com, the best newsletter to stay up-to-date with the React ecosystem:

Updated on June 05, 2022

Comments

  • Sebastien Lorber
    Sebastien Lorber almost 2 years

    I guess there is a good reason, but I don't understand why sometimes we put for example 5 instances having the same webapplications on the same physical server.

    Has it something to do with an optimisation for a multi processor architecture? The max allowed ram limit for JVM or something else?

  • Sebastien Lorber
    Sebastien Lorber over 13 years
    Thanks. In my exemple it was also weblogic ;)