Minimum Hardware Requirements
On small instances, server load is primarily driven by peak visitors.
5 Concurrent Users
2GHz+ CPU
512MB RAM
5GB database space
25 Concurrent Users
Quad 2GHz+ CPU
2GB+ RAM
10GB database space
----------------------------------------------------------RAM---------
-------------------------------------Disk-----------
Use the following formula to determine the number of disk arrays you need:
For example, a system with 1200 MB per second throughput requires at least 1200 / 180 = 7 disk arrays.
Ensure you have enough physical disks to sustain the throughput you require. Ask your disk vendor for the throughput numbers of the disks.
---------------------------
PGA_AGGREGATE_TARGET = 3 * SGA_TARGET.
----------------
-------------------Measure the Cost of Each Operation---------------
Cost per request. You can calculate the cost in terms of processor cycles required for processing a request by using the following formula:
Cost (Mcycles/request) = ((number of processors x processor speed) x processor use) / number of requests per second
For example, using the values identified for the performance counters in Step 2, where processor speed is 1.3 GHz or 1300 Mcycles/sec, processor usage is 90 percent, and Requests/Sec is 441, you can calculate the page cost as:
((2 x 1,300 Mcycles/sec) x 0.90) / (441 Requests/Sec) = 5.30 Mcycles/request
Cost per operation. You can calculate the cost for each operation by using the following formula:
Cost per operation = (number of Mcycles/request) x number of pages for an operation
The cost of the Login operation is:
5.30 x 3 = 15.9 Mcycles
---------------Calculate the Cost of an Average User Profile
Average cost of profile in Mcycles/sec = Total cost for a profile / session length in seconds
Thus, the average cost for the profile is:
147.52/600 = 0.245 Mcycles/sec
---------------------------------Calculate Site Capacity
To calculate these values, use the following formulas:
Simultaneous users with a given profile that your application can currently support. After you determine the cost of the average user profile, you can calculate how many simultaneous users with a given profile your application can support given a certain CPU configuration. The formula is as follows:
Maximum number of simultaneous users with a given profile = (number of CPUs) x (CPU speed in Mcycles/sec) x (maximum CPU utilization) / (cost of user profile in Mcycles/sec)
Therefore, the maximum number of simultaneous users with a given profile that the sample application can support is:
(2 x 1300 x 0.75)/0.245 = 7,959 users
Future resource estimates for your site. Calculate the scalability requirements for the finite resources that need to be scaled up as the number of users visiting the site increases. Prepare a chart that gives you the resource estimates as the number of users increases.
Based on the formulas used earlier, you can calculate the number of CPUs required for a given number of users as follows:
Number of CPUs = (Number of users) x (Total cost of user profile in Mcycles/sec) / (CPU speed in MHz) x (Maximum CPU utilization)
If you want to plan for 10,000 users for the sample application and have a threshold limit of 75 percent defined for the processor, the number of CPUs required is:
10000 x 0.245 / (1.3 x 1000) x 0.75 = 2.51 processors
Your resource estimates should also factor in the impact of possible code changes or functionality additions in future versions of the application. These versions may require more resources than estimated for the current version.
-------------------------------------------------------------------------------
Assessing Your Application Performance Objectives
At this stage in capacity planning, you gather information about the level of activity expected on your server, the anticipated number of users, the number of requests, acceptable response time, and preferred hardware configuration. Capacity planning for server hardware should focus on maximum performance requirements and set measurable objectives for capacity.
For your application, take the information that you derive from Examining Results from the Baseline Applications, to see how your application differs from one of the baseline applications. For example, if you are using the HTTPS protocol for a business application similar to MedRec, you should examine the metrics provided for the heavy MedRec application. Perform the same logical process for all of the factors listed in Capacity Planning Factors.
The numbers that you calculate from using one of our sample applications are of course just a rough approximation of what you may see with your application. There is no substitute for benchmarking with the actual production application using production hardware. In particular, your application may reveal subtle contention or other issues not captured by our test applications.
Calculating Hardware Requirements
To calculate hardware capacity requirements:
Evaluate the complexity of your application, comparing it to one or more of the applications described in Examining Results from the Baseline Applications. The example in Guidelines for Calculating Hardware Requirements identifies this value as the Complexity Factor. If your application is about as complex as one of the baselines, your Complexity Factor = 1.
Consider what throughput is required for your application. In the example, this is called the Required TPS (transactions per second).
Take the preferred hardware TPS value from the appropriate table. The example in Guidelines for Calculating Hardware Requirements identifies this value as the Reference TPS.
Guidelines for Calculating Hardware Requirements
The number of computers required is calculated as follows:
Number of boxes = (Required TPS) / (Reference TPS / Complexity Factor)
For example, if your assessment shows:
Your application is twice as complex as the Light MedRec application; the Complexity Factor = 2.
The requirement is for a 400 TPS; the Required TPS = 400.
The preferred hardware configuration is Windows 2000 using 4x700 MHz processors.
The Reference TPS is 205, from Table 2-3, configuration number lmW1.
The number of boxes required is approximately equal to:
400/(205/2) = 400/102.5 = next whole number, 3.90 rounded up = 4 boxes.
Always test the capacity of your system before relying on it for production deployments.
-----------------------
For data-warehouse project hard disk performance is everything. database cache, indexes, execution plans, memory, number of processors will not make any difference if your server hard disks are slow.
For example you have a table with 10 gigs of data with no indexes. Running select (*) from table will require a full scan of of the table you hardisk does 100mb per sec
10gig/100meg =10 000 /100 = 100sec
Is 100 sec acceptable for you?
---------------------
Disk Size depends on database size
disk speed depends on TPS (transactions per second)
--------------
RAM depends on sort operation,merge join,......no of concurrent sessions....
Using the Sort transform is a fully blocking operation. Whatever rows you're asking the Sort to work on will be blocked in the data flow until the sort completes. The Sort is significantly slower if it can't put all that data into RAM - so that's a critical limit you should design for. Take your max rows that you expect into a Sort multiplied by the row length.
The Merge Join is a partially blocking operation. You don't have to be as concerned about this as the Sort, but if your join is particularly "malformed", it could require a lot of RAM to buffer one of the inputs while the other waits for rows.
--------------------------------
number of processors and speed depends on your data processing
----------------------
Factors Affecting Capacity Planning
There are various factors to consider when conducting a capacity-planning exercise. Each of the following factors has a significant impact on system performance (and on system capacity as well).
- Operational load at backend
- Front end load
- Number of concurrent users/requests
- Base load and peak load
- Number of processes and Instances of processes
- Log size
- Archival requirements
- Persistence requirements
- Base recommendations from vendor
- Installation requirements
- Test results and extrapolation
- Interface Architecture and Performance Tuning
- Processing requirements and I/O operations
- Network bandwidth and latency
- Architecture resilience
- Network/Transmission losses
- Load factor loss
- Legacy interfacing loss/overheads
- Complexity of events and mapping
- Factor of safety
--------------
Hardware capacity determination
The hardware requirements can be evaluated based on the test results for a given set of conditions. There are several tools available to simulate clients (LoadRunner, WebLOAD, etc.). By simulating the transactions mix client load can be generated and load can be increased by adding more concurrent users. This is an iterative process, and the goal is to achieve as high CPU utilization as possible. If the CPU utilization doesn't increase (and hasn't yet peaked out) with the addition of more users, database or application bottlenecks are analyzed. There are several commercially available profilers (IntroScope, OptimizeIt, and JProbe) that can be used to identify these hot spots. In a finely tuned system, the CPU utilization (at steady state) in ideal case is usually less than 70%. While throughput won't increase with the addition of more load, response times, on the other hand, will increase as more clients are added. The capacity of the hardware is the point where the response time increases for additional load.
No comments:
Post a Comment