SOA Hardware Sizing Steps

Selection of deployment hardware is the key in ensuring that your application can support its required non-functional requirements. Consider the following items when choosing the underlying deployment hardware or doing SOA Hardware Sizing:

1. The first decision is whether you are going to deploy into a physical or virtual environment. In our experience, Oracle SOA Suite runs better on physical servers, because it is quite demanding in terms of hardware performance, but we have seen many successful large-scale deployments on virtual servers. For this recipe, we will assume that you are deploying on physical hardware.

2. The second thing to decide is the number of application server instances that you wish to run on each machine, and how much memory you give to application server instances. As a starting point, consider running with two application servers per machine, with each application server running with a 4 GB heap. You can then calculate the approximate amount of memory needed on each machine with the following formula:

Required memory (in GB) = 2 + (n * (1.25 * m))

Here, n is number of instances, and m is their memory footprint.

3. To calculate the approximate number of CPUs that you need on the box (based on a standard Intel type x86 64-bit CPU), use this formula:

Required CPUs = (n*8)/c

Here, n is the number of instances, and c is the number of cores per CPU.

4. Having determined the number of required CPUs and amount of memory, we just need to calculate how many machines we need. As we already have performance profiled our application, we know how many single users an application server can deal with and so we can use the following formula:

Required machines = (1.5*e)/s

Here, e is the estimated number of users, and s is the number of users a single application server can deal with.

In this recipe, we have seen three formulae, and they could do with a little more explanation. These formulae have all been derived based on the experience of our consultants working out in the field on SOA Suite applications; as such, they are guidelines rather than mathematically proven rules.

The first formula is used to derive the amount of memory needed on a machine. It assumes that each application server has a 25 percent overhead for memory usage (hence the 1.25*m), and that the operating system will require around 2 GB memory.

The second formula is used to derive the number of CPUs that you will use. The value of 8 comes from our experience that 8 cores per SOA Suite instance is about the minimum you can get away with in a live system. The final formula calculates the number of machines needed, and uses a factor of 1.5 times the expected load, as it is important to plan in contingency to cope with failures or unexpected load increases. These formulae together should allow you to calculate the approximate amount and size of hardware that you will need to host your live SOA Suite application.

Consider the following items for your virtualized SOA Suite infrastructure:

1. We recommend that you run one instance of Oracle SOA Suite per virtual machine.We have found that this gives the best options for tuning each machine and the best scalability.
2. The second step is to select the number of vCPUs that will be allocated to each server. It is not best practice to allocate vCPU cycles that are not used, as then they cannot be used elsewhere. However, it is also not good to have insufficient vCPUs available to a machine. We suggest starting with two vCPUs per instance, and increasing this if you find that you are bottlenecking on CPU availability.
3. Next, we need to create a memory reservation for the server. You should create a memory reservation large enough to hold the total memory used by the JVM (not just the heap) plus 20 percent.
4. Finally, since virtual servers can suffer from significant clock drift, we recommend that you configure an NTP time source, to keep the servers in sync.

Virtualization hypervisors have many significant optimizations and tricks that they use to allow over allocation of resources, however many of these do not work well with the way that application servers, such as WebLogic, are designed to work.

The largest issue is that of memory management. In general, it is considered best practice to over allocate the memory on a virtualized environment, on the theory that applications will not always need all of the memory allocated to them. However, this does not work well with Java applications, where the way garbage collection works causes large chunks of memory to become free at once, and then it all gets slowly used again until there is none free. When large chunks of memory become free, the VMWare balloon memory hypervisor assumes this is because an application just closed, so it will reclaim the memory from the virtual machine and allocate it to another server. When the JVM then wishes to use it again, the hypervisor has to find more memory to allocate to it, which can result in lengthy pauses. Creating a memory allocation stops this from occurring and ensures that the JVM always has sufficient memory.

The other large problem is clock drift. Since virtual servers only have a virtual hardware clock, its ticks are not as reliable as those of a physical server, resulting in significant clock drift on virtual servers. Since WebLogic clusters rely on timing information to maintain their consistency, and because many timeouts in SOA Suite components are measured in seconds, it is important to configure an NTP source to prevent this drift.

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