| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
| Oracle® Access Manager Deployment Guide 10g (10.1.4.2.0) Part Number E10353-01 |
|
|
View PDF |
Capacity planning is the process of determining which server hardware will best support an Oracle Access Manager deployment based on anticipated usage. The information in this chapter provides a basis for capacity planning that helps ensure that the server hardware in an Oracle Access Manager deployment is adequate for handling peak loads. This chapter includes the following topics:
Estimating the Anticipated Peak System Load for Server Sizing
Component-Specific Capacity Planning and Sizing Considerations
Oracle Access Manager Performance and Scaleability Characteristics
For a general overview of Oracle Access Manager deployments, see Chapter 1.
The goal of capacity planning for an Oracle Access Manager deployment is to maintain an acceptable level of system performance while taking into account a number of different factors:
The time frame in which the users are expected to interact with the system
The user population that is expected to access the system in the given time frame
The average duration of the user session, the duration of the set of transactions
The average number of pages that make up a user session
To access the appropriate hardware for your environment, it is important to understand Oracle Access Manager sizing and scaleability characteristics. Oracle Access Manager components perform well on standard hardware. However, it is more cost effective to have additional capacity than to try to make do with inadequate hardware. The cost of hardware is low compared to the effort required to maintain an under-powered system.
Capacity planning includes:
Making decisions based on the peak load while factoring in performance and scaleability characteristics
The methods and procedures in this chapter can be applied to help you determine the capacity and sizing needs of the deployment, whether you have a single deployment on a single machine or multiple deployments spanning different sites.
Note:
This chapter provides guidelines and examples intended for demonstration purposes only. This chapter may not be specific to the hardware on which you are using the software and does not always provide actual data. Please be advised that Oracle Corporation will not be responsible for any loss, costs, or damages incurred due to the use of the information in this chapter.Appropriate server sizing should ensure that your server hardware can handle the maximum number of operations that can be expected in a particular time interval. Put another way, the server hardware in your Oracle Access Manager deployment should accommodate all users during times of peak load.
Information about the peak load for a given time interval can usually be obtained from:
Oracle Access Manager is a stateless system. Therefore, the estimated maximum transaction throughput and network traffic are critical factors in capacity planning.
This section includes the following topics:
This discussion describes two methods that you can use to measure the load during peak hours in an Oracle Access Manager deployment. From this information, you can estimate your overall system-capacity requirements.
You can compare your load estimates (transactions-per-user-per-second) with your equipment manufacturer's specifications for server hardware. Based on these comparisons, you can determine if the machines you already have are adequate for supporting the estimated load. If existing machines are not adequate, you can base your equipment choices in part on your own throughput requirements.
There are numerous network traffic and Web site usage monitoring tools available for use with the methods described here. However, use of third-party tools is outside the scope of this book.
This discussion includes the following topics:
Note:
Even these methods of estimation may be more rigorous than is required for a deployment of fewer than 20,000 users. Standard server class hardware is adequate for most deployments, as discussed in "Sample Medium-to-Large-Scale Deployment" .Measuring the load includes establishing the highest number of pages and requests per second over a given time interval. This provides you with a good idea about your overall system-capacity requirements.
While you can measure usage over as little as a 24-hour period, Oracle recommends that you measure usage over a period of several weeks. If usage tends to spike during particular weeks of the year, try to obtain measurements from the busiest weeks. From this, you can better extract system-capacity requirements that will hold true even in the busiest period.
To estimate a typical busy load, you multiply the value of an average heavy load by a small integer such as 2 or 3. This allows for usage patterns that are two or three standard deviations higher than an average heavy load, assuming a Gaussian distribution (bell curve) of loads.
To base your estimate on the peak load for the deployment
Measure usage over a significant period of time to obtain measurements from the busiest period.
Choose the highest value seen in a production deployment to use during the next step.
Estimate the parameters of a typical busy load by multiplying the value of an average heavy load by a small integer such as 2 or 3.
Another method that you can use is to measure the active user sessions in a multi-site deployment, as described next.
If you have a multi-site deployment, Oracle recommends that you create a chart of peak usage for all sites, and then estimate your peak load based on the total estimated usage across all sites. One way to do this is to record the number of logged-in users at each site during different times of the day.
Note:
To ensure accuracy using this method, the actual user request rate during peak hours should come from either monitoring the live system in use, or from historical data.A table such as Table 2-1 allows you to estimate the times when the majority of the users on each site are busiest (the shaded area). Each column reflects an hour of the day (local time) that is recorded based on Greenwich Mean Time (GMT). Each row represents the number of logged-in users that were monitored at that hour. According to the example, usage in Mexico City typically starts at GMT 12 and continues through GMT 24. The peak in Mexico City occurs between GMT 16 through 19.
Note:
Mexico City, Mexico is 6 hours behind GMT. Therefore, when it is 6:00:00 PM on Tuesday, February 6, 2007 in Mexico City, GMT is 00:00:00 on Wednesday, February 7, 2007 . Greenwich Mean Time (GMT) or World Time is also known as Universal Time Coordinated (UTC). GMT, World, and UTC time reflects the mean solar time along the Earth's prime meridian. The prime meridian is arbitrarily based on the meridian that runs through the Greenwich Observatory outside of London, England, where the present system originated. UTC is also known as Coordinated Universal Time and sometimes as Universal Coordinated Time; all are abbreviated as UTC and refer to the standard time common to every place in the world (formerly and still widely referred to as Greenwich Mean Time or World Time.Table 2-1 Peak Load Based on Estimated Usage Across Sites
| Peak hours GMT | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Mexico |
0 |
0 |
0 |
3 |
75 |
150 |
175 |
225 |
225 |
225 |
225 |
225 |
225 |
225 |
225 |
175 |
|
Spain |
35 |
50 |
75 |
50 |
25 |
35 |
50 |
75 |
75 |
75 |
75 |
35 |
20 |
0 |
0 |
0 |
|
Egypt |
45 |
45 |
50 |
50 |
50 |
50 |
50 |
55 |
55 |
45 |
30 |
10 |
0 |
0 |
0 |
0 |
|
U.S. |
0 |
2 |
5 |
10 |
30 |
80 |
95 |
95 |
95 |
95 |
86 |
80 |
80 |
90 |
75 |
60 |
|
Columbia |
0 |
2 |
7 |
15 |
30 |
45 |
45 |
50 |
50 |
50 |
55 |
55 |
55 |
55 |
45 |
35 |
|
Costa Rica |
0 |
0 |
0 |
0 |
2 |
5 |
10 |
10 |
10 |
12 |
12 |
12 |
12 |
12 |
12 |
12 |
|
Indonesia |
60 |
45 |
30 |
10 |
4 |
2 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
3 |
5 |
|
Taiwan |
125 |
115 |
100 |
60 |
30 |
5 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
10 |
25 |
75 |
|
Total |
265 |
269 |
267 |
198 |
372 |
425 |
425 |
510 |
510 |
502 |
483 |
417 |
392 |
392 |
385 |
362 |
When estimating the peak load based on the number of logged-in users, Oracle recommends that you assume:
At peak hours all logged-in users are active
Each active user makes an average of 4 requests per minute
Based on the maximum active users (510 users in Table 2-1), you estimate the peak number of requests per second as follows:
For example:
To factor in a standard deviation that is higher than an average heavy load, assuming a Gaussian distribution (bell curve) of loads, you can multiply the estimated requests per second by a small integer: 2 or 3, for example. In this case, you have an estimated peak usage value of:
Requests per second * Standard deviation = Estimated peak requests per second
For example:
34 requests per second * a standard deviation of 2 = 68 requests per second
34 requests per second * a standard deviation of 3 = 102 requests per second
To estimate the peak load based on the number of logged-in users
Create a table that includes all sites in your deployment using Table 2-1 as a guide.
Determine the number of logged-in users for each hour of the day based on either monitoring each site or historical data.
Multiply the maximum number of users by the estimated number of requests per minute (for example, 4 unless you have more accurate data) to determine the total requests per minute.
Divide the total requests per minute by 60 to establish the number of requests per second.
Multiply the requests per second by a small integer (2 or 3) to complete your estimate for a higher than average heavy load.
When there is no simple way to measure usage, or when there is no historical data available, you can use the method described here to project the system usage in an Oracle Access Manager deployment.
Projected Number of Users: Obtain data on the number of users per office from the Human Resources department, or some other authoritative source in your enterprise. From this you can estimate the total number of users accessing resources during peak hours. Be sure to include full-time employees, part-time employees, and contractors in your estimate.
Projected Time Intervals in a Geographically Distributed Deployment: Rather than trying to gather statistics on who is logged in at each site, it may be more practical to identify peak usage time intervals in a geographically distributed deployment and estimate the number of users who are active during those intervals.
For instance, suppose your company has offices in several countries worldwide. You can create a chart of regular office hours plotted against Greenwich Mean Time (GMT). A table such as Table 2-2 allows you to estimate the times when the majority of the offices are busiest (the shaded area), which is a good indication of peak load hours. In Table 2-2, the number 1 within each row indicates 12:00 00AM local time as well as its relationship to GMT. For example, with daylight savings time in effect 12:00AM in Mexico City occurs at 07:00 AM GMT.
Table 2-2 Chart of Office Hours Plotted Against GMT with Daylight Savings Time
| GMT | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
|
|
Mexico |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
|
Spain |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
|
Egypt |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
|
U.S. |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
|
Columbia |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
|
Costa Rica |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
|
Indonesia |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Taiwan |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
A table such as Table 2-3 provides user community statistics per office, from which you can estimate the total number of users accessing resources protected by Oracle Access Manager during peak hours.
Table 2-3 Employee and Contractor Data from an Authoritative Source in Your Company
| Country | Full time | Part time | Contract | Total |
|---|---|---|---|---|
|
Mexico |
3021 |
496 |
35 |
3552 |
|
Spain |
755 |
356 |
5 |
1116 |
|
Egypt |
329 |
275 |
0 |
604 |
|
U.S. |
134 |
25 |
55 |
214 |
|
Columbia |
1290 |
245 |
11 |
1546 |
|
Costa Rica |
175 |
130 |
0 |
305 |
|
Indonesia |
250 |
97 |
18 |
365 |
|
Taiwan |
286 |
88 |
44 |
418 |
You can create a simple throughput projection based on:
An estimate of the total maximum number of users that you expect to be logged in at the same time
The estimated number of transactions per user for a given time period
The estimated transactions-per-second that need to be supported
You can compare your transactions-per-second estimates with claims made by your hardware vendors.
For example, using information in the Table 2-2 and Table 2-3 as a sample, you can project the total users and peak load as follows:
Total Maximum Users: Add together the total number of users on each site. Using the data in Table 2-3 as a sample: 3552+1116+604+214+1546+305+365+418=8120 total users.
Peak Load: This calculation is similar to the one described in "Measuring the Active User Sessions in a Multi-Site Deployment" where you multiply the total users by the estimated requests per minute (4 is a good number unless you have better data) then divide the requests per minute by 60 seconds to establish the requests per second.
Using the data in Table 2-3 as a sample:, you can project:
Based on your human resources data, this is the maximum possible load. Therefore, you do not need to multiply the peak load to take account into the Gaussian distribution of loads. However, you may want consider some safety factors that project the future growth in the system usage.
To project system usage
Create a chart of hours plotted against GMT for your deployment, using the sample Table 2-2 as a guide.
List each GMT hour in a separate column across the top of your table.
Create a row for each office site in your deployment in the left column of the table.
For each site, add a number from 1-24 to indicate local time as it corresponds to the site's offset from GMT using Table 2-2 as a guide.
Determine the hours of peak usage for each site in the table and highlight those.
Create a table template for employee and contractor data for each site using the sample Table 2-3 as a guide.
Obtain the number of users per site from your Human Resources department or another authoritative source in your enterprise.
For each site in your table, enter the number of:
Calculate and enter the total number of users for each site.
Add the total for each site to estimate of the maximum number of users that could be logged in at the same time.
Estimate of the maximum load using the calculation below:
Consider adding in some safety factors to project future growth in system usage.
The "Oracle Access Manager Deployment Overview" in Chapter 1 provided several general recommendations for Oracle Access Manager installations. In addition, the following component-specific considerations should be taken into account:
For performance-tuning guidelines, see Chapter 3.
As discussed in Chapter 1, Oracle recommends installing only one Identity or Access server instance per dedicated machine because 85% utilization is considered a fairly standard load. If you anticipate that the combined utilization for a pair of primary Identity and Access Servers is below 85%, you could consider the following option to help reduce the required hardware estimate:
One host is installed with a primary Identity Server and a secondary Access Server
A different host is installed with both a primary Access Server and a secondary Identity Server
The primary server handles the load unless there is a failover situation. During failover, the secondary server handles the load. If the secondary server becomes activate the utilization of both servers should add up within 85%. If the combined load is projected to be much greater, Oracle recommends that you install the secondary Identity or Access Server on a different machine.
In addition to general Access System recommendations in Chapter 1, Oracle recommends that you take items described in the following discussions into account for Access System capacity planning:
Depending on the load, Access Servers can reach both high CPU and memory utilization. This is critical when planning for the number of Access Servers in your deployment.
System configuration and deployment scenarios also affect performance significantly and are critical factors in capacity planning. For example, the following items are will impact your capacity planning and sizing calculations, as well as your performance tuning decisions. Whether you have the following functions configured to be on versus off will depend on the requirements of your enterprise:
The transport security mode between each tier (whether open or SSL-enabled)
Auditing on
User and group caches
The policy cache
User credential caching
Password policy
The Oracle Access Manager Installation Guide describes transport security modes. For performance tuning recommendations, see Chapter 3. For more information about the features above, see Oracle Access Manager Identity and Common Administration Guide and Oracle Access Manager Access Administration Guide.
A commonly ued WebGate to Access Server ratio is 10:1. A production deployment may require a higher ratio than a development or staging deployment. The actual ratio in your deployment will depend on the actual peak load. By carefully monitoring the situation, you may scale up to higher ratios.
A WebGate may be installed against an existing Web server instance or a new Web server instance.
The number Web server/WebGate pairs depends on usage patterns within the deployment. There is some degradation to baseline Web server performance (about 10% to 20%) when hosting a WebGate. Based on this estimate, Oracle recommends that you add one additional Web server/WebGate pair for every five Web server/WebGate pairs in the deployment. Put another way, to provide the same Web server performance, you should add a sixth Web server/WebGate pair for every five Web server/WebGate pairs.
For details about Web server requirements, see the Oracle Access Manager Installation Guide.
The following topics provide an overview of Oracle Access Manager performance and scaleability characteristics based on tests conducted by Oracle:
Scaling up refers to adding additional processors to your deployment to increase capacity. The results of this test show a fairly nice linear scale up of throughput versus the number of processors.
Figure 2-1 shows the Oracle Access Manager scale-up characteristics in a 4-CPU WintelFoot 1 system. Oracle Access Manager benefits from Hyper-Threading (simultaneous multithreading on the Pentium 4 microarchitecture). With Hyper-Threading enabled, a Pentium 4 processor is treated by the operating system as two processors instead of one.Foot 2 In Figure 2-1, you can plot the throughput ratio of a scale-up test in a 4 CPU system.
Figure 2-1 Oracle Access Manager Scale Up (4 x 2.2 Ghz CPU)
In the bar chart shown in Figure 2-1, throughput-ratio data values are shown along the vertical y-axis. The horizontal x-axis provides the following category data:
P represents the number of processors.
L represents the number of logical processors for the Hyper-Threading equipped processors.
For the same Hyper-Threading equipped processors, with Hyper-Threading turned on the system shows 2 logical processors; if Hyper-Threading is turned off, the system shows 1 logical processor.
1P+1L and 2P+2L data show the performance with Hyper-Threading turned off.
1P+2L, 2P+4L, 3P+6L, and 4P+8L data show the performance with Hyper-Threading turned on.
The throughput ratio of from 1 to 3.4 is calculated by dividing the throughput of each test by the throughput of the 1P+1L results. Therefore, the 1P+1L data is 1.
Scaling out, also known as scaling out horizontally, refers to adding more physical servers to increase the capacity in your deployment.
Figure 2-2 shows Oracle Access Manager scale-out characteristics based on a series of tests that run with from one to four identical Wintel servers. In this series of tests each Oracle Access Manager server was driven to 100% CPU, and then the throughput was measured. You can see an almost straight linear increase ion throughput as the number of servers increase.
Figure 2-2 Oracle Access Manager Scale Out
In the bar chart shown in Figure 2-2, throughput-ratio data values are shown along the vertical y-axis. The horizontal x-axis provides category data for individual configurations that include either 1 or 2 or 3 or 4 identical Wintel servers hosting Oracle Access Manager. Data for a single server was used as the basis for the comparison and given a ratio of 1.0.
The results of this test show how Oracle Access Manager can be scaled out horizontally.
Figure 2-3 shows the impact of various deployment configurations on Oracle Access Manager performance. In this test, the throughput ratio is calculated against Config 1 both because this is the heaviest load option and because this is the most typical deployment.
Figure 2-3 Configuration Impact on Performance
In the bar chart shown in Figure 2-3, throughput-ratio data values are shown along the vertical y-axis. The horizontal x-axis provides category data for individual deployment configurations.
Table 2-4 provides details about each of the four deployment configurations that were used in the throughput ratio tests depicted in Figure 2-3.
Table 2-4 Configuration Settings for Performance Tests
| Config # | Transport Security: Web Components to Identity and Access Servers | Identity Server: Password and Lost Password Policy | Auditing of Identity and Access Servers | User Login | User Credential Caching on Access Server |
|---|---|---|---|---|---|
|
Config 1 |
Simple or Third-Party Certificate |
Enabled |
On |
Form-based |
On |
|
Config 2 |
Simple or Third-Party Certificate |
Enabled |
Off |
Basic-Over-LDAP |
On |
|
Config 3 |
Simple or Third-Party Certificate |
Disabled |
Off |
Basic-Over-LDAP |
On |
|
Config 4 |
Open |
Disabled |
Off |
Basic-Over-LDAP |
On |
This discussion illustrates the results of a baseline performance test. You can use the baseline ratios here in combination with details in "Scale-Up Characteristics" and "Scale-Out Characteristics" to estimate possible server (or server cluster) throughput and capacity.
For this test, 1 million users were loaded into a Sun Java System directory server v 5.2 in a joint Oracle Access Manager Identity and Access System deployment. During this test there were 100,000 active user sessions on the Identity and Access Servers. This deployment configuration includes:
Either Simple or third party certificate to secure communication between Web server components and Identity and Access Servers.
On the Identity Server, password and lost password policy are configured and enabled as follows:
Password policy requires uppercase, number, and lowercase with account lock out after three wrong tries.
Lost password challenge is set, password histories are stored for three tries.
Auditing to file is turned on for the Identity and Access Servers.
Form-based login is configured; required credentials are Username and password.
User credential caching in the Access Server is turned on.
Baseline throughput numbers were obtained from the test setup described above. The results of this test are shown in Table 2-5. The numbers are normalized, and equivalent to the 1P+2L server data shown in Figure 2-1.
Table 2-5 Sample Throughput for Config 1
| Operation | Throughput (Request-per- second-per-CPU) | Comments |
|---|---|---|
|
Self Registration |
32 |
Users perform only self registration |
|
Change Password |
86 |
Users perform only change password |
|
Lost Password |
69 |
Users perform only recover lost password |
|
Login |
116 |
Users perform only login |
|
LoginNavi |
366 |
Users perform login and page navigation |
|
AllMix |
341 |
Users perform all above actions in mixed ratio:
|
As shown in Table 2-5, the LoginNavi operation provides the greatest throughput ratio for requests-per-second-per-CPU; the AllMix operation provides the second greatest throughput ratio. The joint Identity and Access System deployment that produced the test results in Table 2-5 includes Identity and Access Servers, each installed on a single dedicated machine. For more information about the baseline deployment and test cases, see "Sample Medium-to-Large-Scale Deployment" and "Test Cases for Baseline Performance Data".
You can use the sample information in Table 2-5 along with other information in this chapter to determine the load and sizing for the Access Server, and then to extrapolate load and sizing details for the Identity Server.
The sample calculations here are derived from the AllMix throughput data in Table 2-5. When you have a joint Identity and Access System deployed, using the AllMix operation for calculations is fairly realistic. You can also use the LoginNavi throughput for your calculations. For example, based on an AllMix 1P+2L baseline of 341, a scale-up ratio for 1P+2L =1.3 and scale-up ratio for 2P+4L = 2.3 as shown in Figure 2-1, you find that:
2-CPU servers can handle 603 requests-per-second
341:1.3 = throughput:2.3; throughput=341*2.3/1.3 = 603
4-CPU servers should be able to handle 892 requests-per-second (341*3.4/1.3)
2-server clusters with 2-CPUs in each box should be able to handle 1146 requests-per-second (603*1.9)
If your estimated load is 800 requests-per-second, you could choose one of the following hardware configurations for your Access System deployment:
Either a 4-CPU server
Or a 2-sever cluster with 2-CPUs on each server
After sizing the Access Server, you can establish preliminary Identity Server sizing. For Identity Server sizing, you use as a starting point a number that represents half the Access Server firing power. You then refine your calibrations using the estimated transaction throughput data shown in Table 2-5 for each of the following:
Self Registration
Change Password
Lost Password
Using the example of 800 requests-per-second for the Access Server as a basis (with a 2-server cluster deployment for the Access Server), half of this capacity for the Identity Server results in one server with 2-CPUs. However, you must again use the Self Registration, Change Password, and Lost Password details in Table 2-5 to determine whether one Identity Server with 2 CPUs is adequate.
The following procedure provides an example of how you can use the information in in Table 2-5 and the rest of this chapter to determine the load and sizing for the Access Server and the Identity Server.
To determine the load and sizing for the Access Server and the Identity Server
Start with the maximum baseline of requests-per-second-per-CPU using details in Table 2-5 as a guide.
Determine the scale-up ratio using data in Figure 2-1, and ratio for performance versus configuration details in Figure 2-3.
Use a number that represents half of the required Access Server power as a starting point for Identity Server sizing.
Use the Identity System transaction data (Self Registration, Change Password, and Lost Password) in Table 2-5 to determine whether one Identity Server with 2 CPUs is adequate.
This discussion provides details based on use cases created by Oracle to establish a point of reference for Oracle Access Manager components in live deployments of varying size.
A small scale deployment can be estimated as up to 20,000 users. A small-to-medium-sized deployment typically includes up to 100,000 users. Large scale deployments include from 100,000 to 2,000,000 users.
Oracle Access Manager components perform well on standard hardware. Based on tests with various configurations (Config4 shows the highest memory consumption), you may find that:
100,000 active user sessions may consume from 600 MB to 1 GB of memory on an Access Server
With 32-bit systems, the Operating System can usually support up to 2 GB of memory per process
The following topics provide more information about the hardware for Oracle Access Manager deployment sizes:
For small to medium-sized deployments with between 20,000 and 100,000 users, any supported server-class computer and operating system should be adequate for the Identity and Access Server. The following items should be taken into account:
Failover requirements double the number of machines needed. For example, expect to use a minimum of two Identity Servers and two Access Servers for redundancy. When the load is light, these servers may be deployed in a cross-over configuration to optimize hardware utilization. For more information, see "Identity and Access Server Recommendations".
A minimum of 2 GB of memory is needed for each Identity and Access System process.
A minimum of a 2 x 2 GHz CPU system with 4 to 6 GB of memory for each server.
A single dedicated Web server is required for the System Console. This may be deployed on either of the two main Access and Identity Servers to eliminate additional hardware requirements.
For more information about Oracle Access Manager requirements, Web server requirements, and how to prepare for and install components, see the Oracle Access Manager Installation Guide.
For deployments of 100,000-2,000,000 users, Oracle recommends the following hardware for Identity and Access Servers:
Each server should be a 4 x 2 GHz CPU system, or a 2 x 2 GHz system, with 6-8 GB of memory and 2 x 17 GB of mirrored storage. A cluster setup is preferred.
Deplopy the Identity Server in a Delegated Administration model as described in the Oracle Access Manager Identity and Common Administration Guide
For a multi-million user deployment, Oracle recommends that you scale-out with multi-servers using guidelines"Scale-Out Characteristics". Use "Baseline Performance for Identity and Access Servers" to establish your sizing requirements.
For more information about Oracle Access Manager requirements, Web server requirements, and how to prepare for and install components, see the Oracle Access Manager Installation Guide.
In addition to the Lightweight Directory Access Protocol (LDAP) directory server considerations discussed in Chapter 1, Oracle recommends that you consider using multiple LDAP directory servers to balance the load if there are significant update operations that involve the Identity Server (or Identity and Access Servers in a joint deployment). This is especially true for password policy-related operations. In such cases, a multi-master and replica for the LDAP server allows you to configure load balancing between the Identity Server and the LDAP replica (as well as between the Access Server and LDAP replica in a joint Identity and Access System deployment).
When authenticating against the LDAP directory, consider enabling Access Server's user credential caching. This can significantly lower the load on the LDAP directory server during authentication, and improve throughput. For more information, see "Configuring Password Validation by the Access Server".
Disk Space Sizing: A general rule of thumb is to multiply your LDIF file size by 5 to establish the actual LDAP disk space needed for entries and the index. During LDAP initialization, the host computer needs at least the same amount temporary disk space as the LDIF file size multiplied by 5. Each backup copy of your LDAP content requires the same amount of disk space as that of the live LDAP server. For example, an LDIF file for 1 million users is approximately 2 GB in size. When loaded, a 2 GB LDIF file expands to approximately 10 GB. When you take into account the temporary space during initialization, and space required for three full backup copies, you need at least 2 x 5 x 5 = 50 GB disk space:
Memory Sizing: This depends on the LDAP server and the deployment configuration you choose. Oracle recommends that you review the LDAP documentation for your specific directory server and Operating System.
For 32-bit systems, the Operating System may impose a 2 GB limitation per process. For large-scale deployment, a 64-bit system and Operating System are preferred. For more information, see:
Note:
For LDAP directory performance tuning recommendations, see Chapter 2.For performance tuning recommendations, see Chapter 3.
Most currently available directory servers with 2 GB of memory may be adequate for small to medium sized deployments of up to 100,000 users. In addition, Oracle recommends that you:
Use disks that are RAID 01 (striped and mirrored) for the directory server.
Use two replicated directory servers for failover.
Have enough memory to hold two times the LDAP data in memory.
Have an LDAP cache that is large enough to hold the entire database.
Have available 5 GB of disk storage per directory server
For deployments of 100,000 and more users Oracle makes the following recommendations:
Allow 100 GB of disk storage for 2 million users
Segregate physical drives for directory server access and error logs from the attribute data (indexed or not) volume drives
For example, Oracle Internet Directory I/O Subsystem Requirements include arrays of disk drives controlled by disk controllers. It is important to consider performance requirements when you size the I/O subsystem rather than using sizing estimates based only on storage requirements. For more information, see the Oracle Application Server Best Practices Guide.
Allow CPUs 2 or 4 x 2 GHz: If Access Server user credential caching is configured and on, you can significantly lower the LDAP server load and boost performance.
Allocate at least 2 GB of RAM for a 100,000 user directory; at least 4 GB for a very large directory.
Figure 2-4 illustrates hardware and software choices in a lab test environment for a medium to large scale deployment that includes 1 million users in the LDAP directory and 100,000 active user sessions on the Access Server. The baseline throughput numbers were obtained from this deployment and used in"Baseline Performance for Identity and Access Servers".
This deployment is depicted in Figure 2-4 and is installed as described in Table 2-6.
This deployment includes Intel Xenon server-class computers with 2 CPUs, each with 2.8 GHz and 28 SPECInt_rate2000, as shown in Table 2-6.
Table 2-6 Server Installation Details
| Number of Servers | Installed With |
|---|---|
|
5 |
Oracle HTTP Server/WebPass/WebGate |
|
2 |
Access & Identity Server |
|
2 |
LDAP Server |
|
2 |
LR Test Load Drivers |
For the baseline test deployment quoted in this chapter:
The servers (Sun Java System Directory Server, Oracle HTTP Server and Oracle Access Manager), are running on a Windows 2003 Server (SP1).
Each server has 2x2.8 GHz CPUs and 6 GB of RAM, with 140 GB of disk space.
Access Server and Identity Servers are co-located and configured as a primary-secondary setup.
One LDAP directory server is used
WebPass and WebGate are installed on each of five Oracle HTTP Servers
The Policy Manager is installed on one of the Oracle HTTP Server systems
You can scale this deployment as follows:
Increase the number of Oracle Access Manager server hosts to spread the load and offer higher redundancy.
Increase capacity by increasing the amount of CPUs, memory, and disk space to improve server performance
The LDAP directory server supports the addition of new servers for cases where this is desired to improve performance and reliability.
For more information on scaling a deployment, see "Scale-Up Characteristics" and "Scale-Out Characteristics".
The baseline performance data in this chapter is obtained from tests run with the Oracle Access Manager Benchmark Suite Test Application, which contains 100 static HTML pages, each of 14k in size. Data for 1 million users resides in the deployment's LDAP directory server.
The following topics describe scenarios for the Oracle Access Manager Benchmark Suite for Access Server, Identity Server, and an integrated test case for both servers:
The following topics describe baseline performance test cases for the Oracle Access Manager Identity Server:
About 5% of the users will perform self-registrations. Oracle created a self-registration workflow that takes a set of user attributes and enables the user immediately. This is a two step workflow that includes both Self Registration and Enable Password Policy.
For this test case, Oracle configured a password policy that accounts for the syntax and history of the password. 15% of logged in users will try to change their password. Changing a password should succeed approximately 80% of the time. In the remaining 20% of cases, the password may be either too short, too weak, or repeated.
For example after a user incorrectly enters his or her password when asked for his or her challenges, and then they go into the password change screen. For the lost password screen, 10% of wrong user ID entered errors, and 10% of wrong challenges/response, and then 80% of the cases could make it to the next screen (change password).
15% of the logged in users will attempt to change their password. For this test case, Oracle configured a password policy that accounts for the syntax and history of the password. 15% of logged in users will try to change their password. Changing a password should succeed approximately 80% of the time. In the remaining 20% of cases, the password may be either too short, too weak, or repeated.
The following topics describe baseline performance test cases for the Oracle Access Manager for Access Server:
The Login operation consists of one authentication and one authorization operation. Based on the test deployment, 100,000 user sessions are active during a given test. Sessions are not logged out once created. Instead, each session remains quiescent after login.
This test is designed to have about 85% successful authentications and 15% unsuccessful authentications.
The LoginNavi operation consists of one login followed by 10 authorizations yielding a total of 11 operations per user session. The number of sessions and the iteration setting are the same as those in the Login test cases.
The test is designed to produce 5% failed authorizations. It was configured to redirect the authorization failure to a particular page to avoid 404 errors.
All above test scenarios were run together with the mix ratios specified in each scenario. This is a more realistic test case that represents the real-life usage of Oracle Access Manager. If both the Access Server and Identity Server are to be deployed, Oracle recommendeds that you size the system starting with this use case.
Footnote Legend
Footnote 1: Wintel is an industry term for personal computers that are based on the Intel microprocessor with one of the Microsoft Windows operating systems.
