[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. Remember, sizing 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 Each user 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?
Is 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 currently have?
Consider using automated stress testing software that can simulate user load on a system and see how your pre-production test environment reacts to different loads. Forms Users vs Self Service Users Find 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). Find 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. All users 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:
Your 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 Consider 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 account. 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 Consider the 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:
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 date.
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 implementation period.
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?
Homogenous vs heterogenous deployment architectures It 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 Several 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) If 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?
Can 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 correctly. 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 development purposes. Sizing desktop clients The 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 application.
Conclusions So, 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 your system. 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. Remember 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. Related Articles
Steven leads OCI Multicloud Landing Zones. He is a product manager and solution architect with diverse experience as an Enterprise Architect, Database/Integration Architect and CRM Programme Lead across financial, healthcare and sport industries. He was a Global Cloud Solution Architect in Microsoft before joining Oracle, focusing on digital innovation.
