This content has been marked as final. Show 6 replies
Capacity planning is specific to application. It is very hard to generalize those numbers at an application server level.
So, you will not find any documentation regarding it.
Here are some tips:
1. First, we need to determine the maximum load (TPS - Transactions Per Second) a single application server (weblogic) instance can handle. Remember I am not talking about machine, I am referring to application server instance (an instance of a JVM). Let's say one application server instance was able to handle X load.
2. Then we need to determine the CPU utilization and physical memory consumption (mostly based on the heap settings for the server/JVM) on the machine for a single server instance.
3. Now, we will have to determine the number of server instances required to fulfill the production load by calcualating totalProductionLoad divided by "X"
4. Then we will calculate how many application server instances can be hosted on a single machine (number of servers will be determined by point #2 as resources like CPU and physical memory will be shared by application server processes) AND based on that understand how many machines we need.
For point #1 and #2, we will have to perform a load test (performance test) of the actual application to obtain the numbers.
To be (over-)precise, capacity planning is hard and workload-specific unless you have the right tools, at which point it becomes both easier and more general. If you're a mathie, you use PDQ, from Neil Gunther (http://www.perfdynamics.com/), if you're an engineer, you use Teamquest model (temquest.com). Each will build you a predictive time-based model of your workloads, and allow you to vary load and the machine you run it on.
A book: Capacity Planning for Web Performance: Metrics, Models, and Methods by Daniel A. Menasce and Virgilio A.F. Almeida (Prentice Hall, 1998)
Copy and paste:
"Scalability generally refers to the ability of an application to meet additional capacity demands without
significantly affecting the request processing time. The term is also used to describe the ability to increase
the capacity of an application proportional to the hardware resources added. For example, if the maximum
capacity of an application running on four CPUs is 200 requests per second with an average of
1-second response time, you might expect that the capacity for the application running on eight CPUs
to be 400 requests per second with the same 1-second response time. This type of linear scalability is
typically very difficult to achieve, but scalable applications should be able to approach linear scalability if
the application’s environment is properly designed. Good scalability in multi-tier architectures requires
good end-to-end performance and scalability of each component in each tier of the application.
When designing enterprise-scale applications, you must first understand the application itself and how
your users interact with it. You must identify all of the system components and understand their interactions.
The application itself is a critical component that affects the scalability of the system. Understanding
the distribution of the workload across the various tiers will help you understand the components
affected most severely by user activity. Some systems will be database-intensive; others will spend a
majority of their processing time in the application server. Once you identify these heavily used components,
commonly referred to as application hotspots, you can use proper scaling techniques to prevent
This strong understanding of the system itself will also allow you to choose the correct system architecture
to meet the demands of the application. Once you choose the system architecture, you can begin
to concentrate on the application and apply good performance design practices. There are no silver bullets
for choosing the correct system architecture. In our experience, it is best to take an overall system
approach to ensure that you cover all facets of the environment in which the application runs. The overall
system approach begins with the external environment and continues drilling down into all parts
of the system and application. Taking a broad approach and tuning the overall environment ensures that
the application will perform well and that system performance can meet all of your requirements."
A whole overview of available books is provided here: http://docs.oracle.com/cd/E12839_01/web.1111/e13814/appa_reading.htm
ArunBodap, davecb, René van Wijk provide good info.
I have found that Forms and reports 11g is always more memory/SWAP intensive than CPU intensive. In fact the CPU is barely used on every 11g Forms/Reports server i've built, so I don't recommend using more than 4 cores total for two reasons: Oracle Licensing is based on number of cores and you'll find even for a quad core, the CPU will be under utilized. I know its hard to find these types of CPUs now adays, but using Solaris' robust features or Oracle VM should be able to help you with the CPU topic - if you have a server with a large number of cores.
If you're looking for a baseline to start for memory, we always recommend to start with 50MB/user. Another thing to note however, is you'll need a significant amount of SWAP/Virtual Memory. To know how much exactly, you'll have to load test like what Arun, davecb, and Rene pointed out. As it depends on the number of end-users, application features, and end-user characteristics. Reports Servers use a lot of SWAP, I would always consider starting with at least 20GB SWAP no matter how many end-users you have.
I hope this helps.
PITSS | http://www.pitss.com