[Aug. 22, 2011: Updated benchmark whitepaper link]
[Editor: This article from Nick Quarmby presents an introductory-level survey of of the general areas that you should consider when sizing an E-Business Suite environment. Please remember that this blog's mandate is to provide conceptual guidance; we cannot assist directly with specific sizing inquiries for your requirements. If you have specific questions about sizing for your own environment, we strongly recommend that you engage a specialist from your hardware vendor, Oracle Consulting, or both.]
We're often asked in Service Requests (SRs) to advise on the appropriate hardware specification for an Oracle Applications environment. The term most commonly used term for this exercise is 'sizing' and it is the process of working out how much disk space, memory and processing power you will need to run your Oracle Applications environment. Our Applications Performance group publishes performance benchmarks and sizing-related whitepapers here:
The reality is that sizing an Oracle Applications environment is far too complex a task to carry out through the limited interface of a Service Request (SR). There are a lot of factors to take into consideration. Underestimating the hardware that you need will have performance and budgetary consequences and overestimating the hardware you need wastes valuable resources. Poor performance of a system when it is rolled out will easily undermine confidence in a project. The functionality of the software may be perfectly good but if it is delivered on inappropriately sized hardware it may take time to fix and the integrity of the whole project may be called into question.
This article will not conclude by telling you exactly how to size your
hardware and the reasons for that will become apparent, but what I hope
it will do is help you, as an Applications DBA, understand what factors
you might need to consider when you are required to specify hardware
for your Oracle Applications environment.
hardware is not just about making sure the system you plan to implement
shortly will run. You need to take into account future expansion. You
might be lucky and just have an instinctive feel for the right size
hardware for the job. Alternatively, you might currently have an Oracle
Applications environment on hardware that you know intimately and
therefore you also know that if you simply upgrade to the latest model
then that's going to serve your purpose. Easy. Wouldn't it be nice if
all decisions were so straightforward?
Sizing for the rest of us
is not such a simple process and has to take into account many factors.
With that in mind, I'd like to go into a bit more detail of what you
need to think about when sizing your hardware.
Choosing your server hardware
Oracle Applications Support will
cannot tell you what hardware or operating system to use.
You should already have a very good idea what hardware supplier you are
going to go with. We will happily advise on certified combinations once
you know the platform you plan to use. Remember Oracle Applications is
certified on operating systems, not specific models of hardware. Here's a useful definition of 'platform'
within the context of
Oracle E-Business Suite.
Number of concurrent E-Business Suite users
that connects to Oracle E-Business Suite will require an amount of memory
on the application and database tier. You should consider:
- The maximum number of
users that will need to be logged in concurrently on your system
- The nature
of the work (the transactional mix) these users will be performing
- Whether they will
require access via the Oracle Forms interface or whether they will only
access Oracle Applications through the Oracle Applications Framework
(Self Service) interface.
Remember, only a proportion of the
registered EBS users will be using it concurrently. You may have users accessing the system from different timezones; in this case, usage is distributed throughout a 24 hour period. You probably
do not need hardware that can cope with all registered users accessing the system simultaneously but you should also consider times
when there may be surges in demand and ensure you size your system
accordingly for these busy periods.
Considerations for user load analysis
Look at a typical day for
your production environment:
- When are the periods of peak usage?
your hardware sized to handle these peaks?
- Does your system have surges
in demand at month end or year end?
- Is your system overloaded at
certain times of the day?
- If so, can some of the load be moved to
quieter periods in the day and therefore maximize the resources you
Consider using automated stress testing software
simulate user load on a system and see how your pre-production test
environment reacts to different loads.
Forms Users vs Self Service Users
out how many users will use the Self Service interface. These users
require a small amount of fixed memory on the application tier.
Depending on their activity, additional memory is then allocated and
de-allocated on an ad hoc basis via the Java Virtual Machine (JVM).
out how many users will require the Oracle Forms (classic) interface.
These users also require the same small amount of fixed memory as Self
Service users but each user also requires a fixed allocation of memory
on the application tier for the Oracle Forms service. This fixed memory
is required for the duration of their Oracle Forms session, or until
their session times out due to inactivity.
initially connect to a JVM and correctly sizing JVMs on the application
tier is a frequently discussed topic. For more information about performance tuning and JVM optimization, see:
users' memory requirements on the database tier are dependent on the
nature of the queries they execute. Controlling the nature of these
queries should be part of the planning process for your implementation.
Planning for load from Concurrent (Batch) Processing runs
the amount of concurrent processing your system will be required to
handle. There may be quiet periods during which you can use the Work
Shift functionality of the Concurrent Manager to schedule non-urgent
concurrent processing but in a busy 24/7 environment you will always be
required to schedule some concurrent processing simultaneously with
normal usage. Your system must be sized to take this usage into
Scalability and additional server nodes
When a machine's resources are
so heavily-used that performance begins to be affected then you must
consider additional hardware. Adding more memory, disk, or processing
capability to an existing node is one option. Consider the memory and
processor limitations of the hardware you plan to purchase and consider
what it would take to fully load that environment. Is this sufficient
for your anticipated future needs? You may find that instead of
upgrading an existing node that you could add an additional machine to
share the load.
Adding nodes at the application or database
tier and distributing utilisation across nodes using load balancers
and/or Oracle Real Application Clusters (RAC) is a common way of
creating an easily (and often very cost-effective) scalable
environment. Consider a multi-node architecture using low cost hardware
when sizing your environment rather than specifying very high
specification single node solutions.
Taking future requirements into account
scalability of the hardware you are implementing and whether it will be
expandable to fulfill your future requirements. Sizing
new hardware not only needs to take into account your immediate needs;
you also need to consider your future requirements:
Homogenous vs heterogenous deployment architectures
- You may be planning
a new system offering a number of Oracle Applications products but your
future plans may include implementing additional products at a later
- You may be considering installing additional languages.
- You may
be considering a phased rollout of Oracle Applications across your
organisation where the number of users will increase over the
- You may be considering external feeds coming
into your system. Are there plans to to implement an external portal to
allow your customers to access Oracle Applications?
may seem strange to consider mixing platforms within a single
E-Business Suite environment, but this is not as unusual as some
people think. A common arrangement is to have multiple commodity Linux
boxes running the application tier, accessing a database tier that is
running on different hardware and operating system. We run this kind of architecture at Oracle with our own E-Business Suite implementation
It may cost-effective -- and in some cases desirable -- to use one
platform at the application tier and another platform at the database
tier. We generally do not recommend mixing
platforms at the application tier level as this introduces patching
complications and also an element of uncertainty when tracing problems.
In a mixed platform environment the database tier should
be dedicated to running the database. Concurrent processing should
ideally be handled at the application tier level. This again reduces
duplication during patching and should also simplify scalability.
This strategy makes it comparatively easier to increase the throughput of your system by adding a node at the
application tier or adding a RAC node at the database tier.
Monitor usage on an ongoing basis
tools allowing you to monitor the usage of resources in your
Oracle Applications environment. Oracle Enterprise Manager
can be used to
monitor the database. The Applications Management Pack
can be used to
monitor Oracle E-Business Suite-specific resources.
High Availability (HA) and Disaster Recovery (DR)
your Oracle Applications environment is critical to your business you
will need to consider what happens in the event of any sort of failure. These are factors
that need to be considered at the sizing stage:
- Can your business afford to lose the system for any amount of time?
you identify single points of failure?
- Do you need to design
contingency into your system to avoid such failures?
Once you have
sized your system to run your production environment you will need to
consider whether you might need some sort of standby system running in
a separate data centre in the event that you lose your production
environment. If you need this standby system to take over and
effectively replace your production environment it will need to be
correspondingly sized. If you only wish your standby to offer a reduced
service then you can downsize it accordingly, but you must still size it
Considerations for test systems
Your test system will need to
be able to run copy of your production environment. Whilst test
hardware may not require the raw processing power or memory of your
production environment, it will still need to have sufficient disk
capacity to accommodate at least one and (possibly more) copies of your
production environment. All patches and upgrades should be tested on a
full copy of your production environment before you contemplate
applying them in production.
Your test platform should always
use the same operating system as your production platform. This not
only means you are testing as true a copy of production as possible but
also allows you to exploit cloning functionality to quickly create and
deploy exact copies of Oracle Applications environments for test and
Sizing desktop clients
following Notes suggest minimum specifications for desktop clients to
Oracle Applications. These are very modest specifications and are
likely to produce correspondingly modest performance. I think it's
always a good idea to get end users involved and establish what their
expectations regarding performance are. An overspecified client will
not hide an under-performing back end application but a poorly
specified client can easily undermine a user's willingness to use an
For a more detailed discussion about determining your specific desktop client requirements, see:
having considered all of the above, who can you talk to in order to get
more information about sizing? Your best friend at this time is your
hardware supplier and perhaps, a third party consulting organisation
(or better still Oracle Consulting) who are helping you to implement
Most of the major hardware manufacturers can help with sizing
their hardware for the E-Business Suite. They can also advise on the
latest technologies available in their hardware to exploit
virtualisation, scalability, high availability etc. They will probably
ask you to consider some, or all, of the above factors.
there is usually more than one answer to a question. Consider whether
you require a hardware or software solution to your particular
requirements. Make sure the recommendations you get from your hardware
supplier will add value and are compatible with your Oracle
Applications implementation. Review software solutions against hardware
solutions and decide which provides the best performance, scalabilty
and availability for your requirements.
This article does not
offer a conclusive approach to sizing as it is always specific to
the organisation implementing the system. What I hope it does is help
you appreciate that sizing is more complicated than taking a headcount
of your users, listing the products you plan to use and running these
figures through a simple algorithm. Correct sizing is key to a successful implementation.