weblogic server capacity planning considerations

Oracle Weblogic Server

We need to consider below things while calculating server scaling:

How much flexibility do you wish to retain to run, manage and maintain applications independent of each other.
Very large number of applications and servers within a single domain can be more difficult to manage than applications that have been partitioned in some manner to run on separate management domains.
Clusters require inter process communication among cluster members. This is not a significant consideration for the vast majority of WebLogic Server clustered deployments. However, as the number of servers grows very large, and under heavy application load, inter process communication can affect application performance.

Example Considerations:

1) N number of apps( N >200) in a single cluster
— Maximum application interdependence.
Your entire architecture becomes vulnerable to the weakest link, or the most volatile application.

— Management scaling issues
There are a number of scaling issues driven by the (N apps) by (M managed servers) scaling problem.   For the sake of an example, let’s say that to support 200 apps you will need to scale up your cluster to 40 servers.

— Raw performance and cluster scaling issues
The aggregate performance requirements of all these apps may drive you to a cluster/domain deployment size of more than 50 managed servers.   While there are many WebLogic Server clusters that are larger than 50 managed servers, they are a typical, with most clusters being much smaller (8 servers or less). It’s recommended a 32-server cluster (and 32-server domain) as a nominal limit for an application architecture.

2) N apps in N individual domains (N = 100)

— More servers than really required
The recommended practice is to have a separate admin server (from the managed servers).  If you have HA or any scaling requirements in your apps you typically deploy 2+ managed servers.  So such a topological appraoch could lead to requirements for 3+ servers per domain.
As a starting point, applications with different business characteristics (and therefore different development teams, different business owners, different performance, HA, server patching, app maintenance, deployment, configuration management, monitoring and security requirements) should be segregated into different domains. For example keep your intranet apps, external but non-mission critical apps, and external mission-critical apps separate.

It’s recommended a 32-server cluster (and 32-server domain) as a nominal limit for an application architecture. Clusters and domains larger than this size are generally required only for the most demanding applications, and should be deployed only after specific analysis of application performance, management use cases, and long-term maintainability.  If necessary, assess further partitioning of these applications into separate domains.  In some cases an application may need this many servers, but this is rare and in any case such an app is typically mission critical and warrants special review.
It’s recommended using a (N apps) * (M managed servers) “metric” as part of your architectural evaluation, in order to highlight potentially problematic domains, and to identify opportunities for partitioning very large domains into smaller units, and to reduce this metric for any particular domain.  For example:

All 250 apps on a 40 managed server cluster/domain -> 10,000 apps*servers in this domain
250 apps into 4 different clusters/domains of 62 apps and 10 managed servers each -> 620 apps*servers per domain
250 apps into 10 different clusters/domains of 25 apps and 4 managed servers each -> 100 apps*servers per domain
250 apps into 25 different cluster/domains of 10 apps and 2 managed servers each -> 20 apps*servers per domain
250 apps into 200 different clusters/domains of 1 app and 2 managed servers each -> 2 apps*servers per domain

Some rough guidelines for what these metrics might indicate:
– 10,000 – An extremely complex domain environment which will be complex to maintain and manage over time, and should be partitioned into smaller domains.

– 1,000 – Moderately complex clusters/domains, further partitioning should be evaluated.

– 100 – Manageable environment if it meets customer needs

– 10 – Basic domains

– 1 – overly simplistic individual domains


In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.

6 Responses

  1. Subu says:

    Can you clarify you statement “It’s recommended a 32-server cluster (and 32-server domain) as a nominal limit for an application architecture” ?

    When you say “32-server”, can you clarify you mean “32-physical servers”

    • TechPaste.Com says:

      32 managed servers (total count-including servers in all clusters) per domain or 32 managed servers(non clustered) within one domain

      • Vin says:

        32 managed servers is very small. We have domains that are much larger (50 to 200) and have been working fine since version 8.1. on what do base this assumption

        • TechPaste.Com says:

          Yes, Vin you are right 32 managed servers might be very small compared to some of the setup which are really huge. Here we have mentioned 32 managed servers as we had done all the testing on these in house setups only. We are yet to test huge deployments like 80 to 250+ servers.

          • deepa says:

            WE have more than 50. I spoke to my Oracle support guy and he said there is no such limit.

          • TechPaste.Com says:

            Yes Deepa. There is no such limit. but here the testing scope was for 32 managed servers.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.