When you do your first WebLogic deploy, you have the option to ‘Deploy the Java web applications to a single managed server.’ What does that mean and when should you use it?
Deploying to a single managed server means that all WebLogic components share a single WebLogic deployment instead of each being deployed to their own instance, complete with their own Windows service. They share a single Java engine, a single memory stack and a single WebLogic process. It means less memory, less CPU and fewer system resources are used.
Sounds great, doesn’t it? So why isn’t that just the way we do it? Why is it used only in rare circumstances?
All that resource ‘savings’ comes at a cost and with restrictions. First, a ‘single managed server’ is just that – ONE server. So if your environment will be larger than a single server with web components, you can’t use this option. There’s some exceptions to that (i.e. Essbase, and IIS components don’t count for this purpose), but anything tied to a WebLogic service has to be in one location.
Next, they all share the same pool of memory. While this means less total overhead, because you now only have one item instead of 10, it also means a “traffic jam” of sorts can happen. Take this simplified example:
Running a FR Report against a Planning application
- User invokes from Workspace (WL item 1)
- User rights to report and Planning are validated from Shared Services (WL item 2)
- Reporting core accesses the report (WL item 3)
- Planning is used to pull needed information (WL item 4)
- FR Web presents the report (WL item 5)
All this happens for a single report. When these items are separate, each WL instance will spike to do the work as quickly as possible. When they share the same memory, it’s not a case of “you take your turn, then I get mine”. Instead they all want the memory at the same time. Not a problem for small reports or small loads, but as the reports get bigger and more run at the same time, we have problems.
A note on the example above. In 11.1.2.x, Workspace and Shared Services will share the same WebLogic deploy even if it’s not a single managed server. They both deploy together and this is the instance that is used if you decide to deploy to a single managed server.
Finally, when too many users need access to the system, a single managed server simply can’t handle it. Think of it this way – would you rather have 100 2-lane roads or one massive 20-lane road? There is a limit to the number of concurrent connections WebLogic can handle (no matter how well tuned). Once you get a significant number of users, you need more. It’s a case of 'many hands make light work.'
So while a single managed node works well for a sandbox or a small development environment, reducing the needed resources to run products, it isn’t intended for enterprise-level production environments.