WIXLIB

1.3Test ScenarioResultsHTTPS Authentications using Secure Name/Password – Basic650 logins per secondHTTPS Authentications using Name/Password –Form650 logins per secondHTTPS Authentications using Secure Name/Password – Form650 logins per secondHTTPS Login with Roles/Access GatewayAuthorization500 logins per secondHTTPS Login with Identity Injection400 logins per secondHTTPS Login with Form Fill450 logins per secondHTTPS Authorizations with 10 page request2500 authorized pages per secondAccess Manager ApplianceThe following performance numbers are recorded per minute to show how the system performs:Test ScenarioResultsHTTPS Public (a user accessing a single page in asession)2808K requests per minute with a throughput of3000 Megabits per minuteHTTPS Public (a user accessing 10 pages in a session)1800K requests per minute with a throughput of6600 Megabits per minuteHTTPS Authentications using secure name/password - form33K logins per minuteHTTPS Authorizations24K authorized pages per minuteHTTPS Authorization with 10 page requests168K authorizations per minuteThe following performance numbers are recorded per second to show how the system performs:Test ScenarioResultConcurrent Sessions in a 4-node Access Gatewaycluster560K sessions in the cluster (approximately 140Ksessions per server)Concurrent Sessions in a 4-node Identity Servercluster720K sessions in the cluster (approximately 180Ksessions per server)HTTP Public48K requests per secondHTTPS Public47K requests per secondHTTPS Authentications using Name/Password –Basic650 logins per secondAccess Manager Performance9

1.4Test ScenarioResultHTTPS Authentications using Secure Name/Password – Basic660 logins per secondHTTPS Authentications using Name/Password –Form550 logins per secondHTTPS Authentications using Secure Name/Password – Form560 logins per secondHTTPS Login with Roles/Access GatewayAuthorization400 logins per secondHTTPS Login with Identity Injection300 logins per secondHTTPS Login with Form Fill290 logins per secondHTTPS Authorizations with 10 page request2800 authorized pages per secondAccess Gateway Service on WindowsThe following performance numbers are recorded per minute to show how the system performs:Test ScenarioResultsHTTPS Public (a user accessing a single page in asession)1700K requests per minute with a throughput of1800 Megabits per minuteHTTPS Public (a user accessing 10 pages in a session)1340K requests per minute with a throughput of5000 Megabits per minuteHTTPS Authentications using secure name/password - form28K logins per minuteHTTPS Authorizations27K authorized pages per minuteHTTPS Authorization with 10 page requests114K authorizations per minuteThese performance numbers are recorded in second to show how the system performs:10Test ScenarioResultsConcurrent Sessions in a 4-node Access Gatewaycluster160K sessions in the cluster (approximately 40Ksessions per server)Concurrent Sessions in a 4-node Identity Servercluster400K sessions in the cluster (approximately 100Ksessions per server)HTTP Public27K requests per secondHTTPS Public28K requests per secondHTTPS Authentications using Name/Password –Basic530 logins per secondAccess Manager Performance

1.5Test ScenarioResultsHTTPS Authentications using Secure Name/Password – Basic520 logins per secondHTTPS Authentications using Name/Password –Form470 logins per secondHTTPS Authentications using Secure Name/Password – Form460 logins per secondHTTPS Login with Roles/Access GatewayAuthorization450 logins per secondHTTPS Login with Identity Injection380 logins per secondHTTPS Login with Form Fill450 logins per secondHTTPS Authorizations with 10 page requests1900 authorized pages per secondIdentity Server as an OAuth 2.0 Identity ProviderThe following table lists different OAuth requests on a single node Identity Server and performancefor each request:TestScenarioAccess ManagerPerformanceClient credentials flowwithout a refresh tokenUsers request for an access token in the clientcredentials flow without a refresh token.820 tokens per secondClient credentials flowwith a refresh tokenUsers request for an access token in the clientcredentials flow along with a refresh token.800 tokens per secondResource owners flowwithout refresh tokensUsers request for an access token in the resourceowners flow without requesting for a refreshtokens.600 tokens per secondResource owners flowwith refresh tokensUsers request for an access token in the resourceowners flow with refresh tokens.200 tokens per secondAuthorization code flowwithout refresh tokensAuthenticate and request for an authorizationcode and using the authorization code request foran access token without requesting for refreshtokens.120 tokens per secondAuthorization code flowwith refresh tokensAuthenticate and request for an authorizationcode and using the authorization code request foran access token with refresh tokens.110 tokens per secondImplicit flow – accesstokensRequest for an access token in the implicit flow.140 tokens per secondImplicit flow – ID tokensRequest for the ID token in implicit flow.140 token per secondImplicit flow – Accesstoken ID tokensRequest for an access token and an ID token in theimplicit flow.130 tokens per secondAccess Manager Performance11

TestScenarioAccess ManagerPerformanceToken validationValidate an access token against the tokeninfoendpoint.540 validations per secondToken refreshGetting an access token by submitting the refreshtoken.460 token refreshes persecondUser AttributesFetching the user attributes against the userinfoendpoint540 requests per secondFor information about the test environment, see Section A.3, “Test Environment: Identity Server asan OAuth 2.0 Identity Provider,” on page 39.NOTE: To improve the performance of OAuth requests, scale Access Manager componentshorizontally by adding additional components to the cluster.1.6Advanced Session AssuranceThis section explains the performance test results and performance impact of enabling AdvancedSession Assurance on authentication and sessions in Identity Server and Access Gateway. Accessing Login Pages for the First Time: A delay occurs when a user accesses the login page forthe first time after enabling Advanced Session Assurance. This delay is due to the downloadingof initial login pages and associated java scripts to the browser. The subsequent requests willnot be delayed as Java Scripts are cached in the browser during the first attempt. Advanced Session Assurance Parameters: An additional delay may occur in the loginperformance if the following parameters are enabled for session assurance. HTML5 Capabilities System Fonts Webgl MetadataThis delay is due to the client side browser processing for the additional parameters. Theseparameters do not impact the server side processing. Section 1.6.1, “Impact of Enabling Advanced Session Assurance on Identity ServerPerformance,” on page 13 Section 1.6.2, “Impact of Enabling Advanced Session Assurance on Access GatewayPerformance,” on page 13NOTE: For information about the test environment, see Section A.4, “Test Environment: AdvancedSession Assurance,” on page 40.12Access Manager Performance

1.6.1Impact of Enabling Advanced Session Assurance on IdentityServer PerformanceUse case: A user logs in to Identify Server ([https:// idp url /nidp/app/) continuously with theSecure Name Password form contract with Advanced Session Assurance configured at IdentityServer.1.6.2With Session AssuranceWithout SessionAssurancePerformance ImpactLogins Per Second230 logins per second250 logins per second8%Number of Sessions 200 K sessions 200 K Sessions0Impact of Enabling Advanced Session Assurance on AccessGateway PerformanceUse case: A user accesses the protected resource with the secure name password form contractwhen Advance Session Assurance is enabled for both Identity Server and Access Gateway.1.7With Session AssuranceWithout SessionAssurancePerformance ImpactAccess Gatewayrequests Per Second130 requests per second160 requests per second18%Number of Sessions 200 K sessions 200 K Sessions0Components ScalabilityThe goal of the scalability tests is to validate the architecture and show the size of clusters/components used.ComponentNumber of DevicesIdentity Servers12Access Gateway Appliance18Linux Access Gateways8LDAP Servers8Web t Users on Access Manager40000 sessions per Access GatewayAccess Manager Performance13

14Access Manager Performance

2Sizing Guidelines2The following recommendations are based on the test results: If your environment demands a large number of users active throughout the day, scaling thememory to hold these user sessions is recommended. For example, all users keep their portal ormailbox open throughout the day. However, if the environment demands more users activitiessuch as logins per second / requests per second, scaling the CPU is recommended for fasterprocessing. For example, trading systems where a large number of users log in at the same timeand leave the session quickly. A total number of users in the LDAP user store is not significant for determining hardwarerequirements for Access Manager components. When usage is high for accessing web servers and applications, more Access Gateways arerequired. When usage is high for users and authentication, more Identity Servers are required. Two nodes in a cluster are given as the minimum recommended configuration to have faulttolerance. The setup needs to be evaluated in a real-world usage of the use case.In this Chapter Recommendation based on Logins per Second Recommendation based on Active Sessions Recommendation based on Access Gateway Hits per Second Horizontal and Vertical Scaling Sizing Recommendation for Analytics Server2.1Recommendation based on Logins per SecondLogins per SecondNumber of NodesServer Configuration of EachNodeLess than 2002 Identity Server4 X CPU, 16 GB Memory2 Access Gateway200 - 5004 Identity Server4 X CPU, 16 GB Memory4 Access Gateway500 - 6506 Identity Server4 X CPU, 16 GB Memory6 Access GatewaySizing Guidelines15

2.22.32.4Recommendation based on Active SessionsActive SessionsNumber of NodesServer Configuration of Each NodeLess than 200,0002 Identity Server and 2 Access Gateway2 X CPU, 16 GB Memory200,000 – 300,0002 Identity Server and 2 Access Gateway4 X CPU, 32 GB Memory300,000 – 400,0004 Identity Server and 4 Access Gateway4 X CPU, 32 GB MemoryRecommendation based on Access Gateway Hits perSecondHits Per SecondNumber of NodesServer Configuration of Each NodeLess than 10,0002 Access Gateways2 X CPU, 16 GB Memory10,000 – 20,0002 Access Gateways4 X CPU, 16 GB Memory20, 000 – 40,0002 Access Gateways8 X CPU, 16 GB MemoryHorizontal and Vertical ScalingThese tests include the following Access Manager operations: Logins (See Login Performance) Active Sessions (See Scalability of Active Users Sessions) Hits (See Access Gateway Hits Scalability) Throughput (See Access Gateway Throughput Scalability)NOTE: For more information, see Test Environment: Vertical and Horizontal Scalability.2.4.1Login PerformanceThis scope of this test is measuring the login performance when a user accesses the resourceprotected with the Secure Name Password Form contract. “Login Performance with CPU Scaling” on page 17 “Login Performance with Memory Scaling” on page 18 “Login Performance with Number of Nodes in a Cluster” on page 1916Sizing Guidelines

Login Performance with CPU ScalingIn this test, memory is kept constant at 32 GB and Tomcat is assigned with 16 GB in Identity Serverand Access Gateway. CPUs are increased in the following order 1, 2, 4, 8, and 16 and performance ismeasured at each CPU level.Logins Per Second160140120Logins Per Second10080604020024681012141618Number of CPUsSizing Guidelines17

Login Performance with Memory ScalingIn this test, the number of CPU is kept constant at 16 for Identity Server and Access Gateway.Memory is increased in the order 8 GB, 16 GB, 32 GB, and 64 GB. Also, Tomcat is assigned with 70%of the available memory. Performance is measured at each memory level.Logins Per Second160140120Logins Per Second10080604020010203040Memory in GB18Sizing Guidelines506070

Login Performance with Number of Nodes in a ClusterIn this test, each node is assigned 8 CPU and 16 GB memory. Performance is measured by increasingthe number of nodes in the cluster.Logins Per Second700600Logins Per Second50040030020010001234567Number of Nodes in a cluster2.4.2Scalability of Active Users SessionsTest: Scaling and maintaining the active users sessions by periodically increasing users' logins andrefreshing the active session within session timeout period. “Active Sessions Scalability with Scaling CPU” on page 19 “Active Sessions Scalability with Scaling the Memory” on page 20Active Sessions Scalability with Scaling CPUIn this test, memory is kept constant at 32 GB and Tomcat is assigned 16 GB in Identity Server andAccess Gateway. The number of CPU is increased in the order 1, 2, 4, 8, and 16, and performance ismeasured at each CPU level.Sizing Guidelines19

300000250000Ac ve er of CPUsActive Sessions Scalability with Scaling the MemoryIn this test, the number of CPU is kept constant at 16 for Identity Server and Access Gateway.Memory is increased in the order 8 GB, 16 GB, 32 GB, and 64 GB. Tomcat is assigned with 70% of theavailable memory. Performance is measured at each memory level.Ac ve Sessions300000250000Ac ve Sessions20000015000010000050000010203040Memory in GB20Sizing Guidelines506070

Access Gateway Hits ScalabilityTest: Accessing a public resource through Access Gateway. Public resources are static pages of size 60KB containing several hyperlinks to the same originating web server. In this test, the number of hitsper second is measured. “Access Gateway Hits with Scaling CPU” on page 21 “Access Gateway Hits with Scaling the Memory” on page 22Access Gateway Hits with Scaling CPUThe memory is kept constant to 32 GB and Tomcat is assigned 16 GB for Access Gateway. Thenumber of CPU is increased in the order 1, 2, 4, 8, and 16. Performance is measured at each CPU.Hits Per Second300002500020000Hits Per Second2.4.3150000100005000024681012141618Number of CPUsSizing Guidelines21

Access Gateway Hits with Scaling the MemoryIn this test, CPUs are kept constant at 16 for Access Gateway. Memory is increased in the order 8 GB,16 GB, 32 GB, and 64 GB. Tomcat is assigned with 70% of the available memory. Performance ismeasured at each memory level.Hits Per Second2650026000Hits Per ry in GB2.4.4Access Gateway Throughput ScalabilityTest: Accessing a public resource through Access Gateway. The public resources are static pages ofsize 8 MB that have several hyperlinks pointing to the same originating web server. Measure thethroughput per second. “Access Gateway Throughput with Scaling CPU” on page 23 “Access Gateway Throughput by scaling the Memory” on page 2422Sizing Guidelines

Access Gateway Throughput with Scaling CPUIn this test, memory is kept constant at 32 GB and Tomcat is assigned 16 GB for Access Gateway. Thenumber of CPU is increased in the order 1, 2, 4, 8, and 16. The performance is measured at each CPUlevel.Throughput (kbps)50000450004000035000Throughput Number of CPUsSizing Guidelines23

Access Gateway Throughput by scaling the MemoryIn this test, the number of CPU is kept constant at 16 for Access Gateway. Memory is increased in theorder – 8 GB, 16 GB, 32 GB, and 64 GB. Tomcat is assigned with 70% of the available memory.Performance is measured at each memory level.Throughput (kbps)455004500044500Throughput emory in GB2.5Sizing Recommendation for Analytics Server Section 2.5.1, “Hardware Requirements for Analytics Server,” on page 25 Section 2.5.2, “Analytics Server Data Retention,” on page 2524Sizing Guidelines70

2.5.1Hardware Requirements for Analytics ServerFor the demonstration purpose, the 50 GB hard disk is required. For a production environment, thehard disk requirement depends on the Access Manager login pattern for a day. For other systemrequirements for Analytics Server, see “System Requirements: Analytics Server”.The following recommendations consider only Analytics Server-specific Access Manager Auditevents. For information about Analytics Server events, see “Enabling Events for Each Graph” in theAccess Manager 4.5 Administration Guide.Any change in Access Manager Audit events selection changes the disk requirement.2.5.225000 logins per day50000 logins per day100000 logins per dayNumber of daysDisk space in GBDisk space in GBDisk space in 7583.95Analytics Server Data RetentionThe events stored in Analytics Server are retained in the local storage for 180 days. After 180 days, allevents are purged from Analytics Server.Sizing Guidelines25

26Sizing Guidelines

3Access Gateway Performance in AccessManager 4.43Access Manager 4.4 onward, Access Gateway is upgraded to Apache 2.4. Therefore, Access Gatewayperformance is significantly improved.The following graphs show the overall public request performance improvement in Access Manager4.4 over Access Manager 4.3:HTTPS transactions per secondHTTP transactions per secondAccess Gateway Performance in Access Manager 4.427

Data transfer rate – HTTPSData transfer rate – HTTP28Access Gateway Performance in Access Manager 4.4

AAdditional InformationA Section A.1, “Test Strategy,” on page 29 Section A.2, “Tuning Parameters,” on page 34 Section A.3, “Test Environment: Identity Server as an OAuth 2.0 Identity Provider,” on page 39 Section A.4, “Test Environment: Advanced Session Assurance,” on page 40 Section A.5, “Test Environment: Vertical and Horizontal Scalability,” on page 42A.1 Test StrategyThe test setup represents a medium-sized business with heavy traffic to help predict performancefor both smaller and larger implementations. The performance, reliability, and scalability tests coverthe critical areas that you need to know for designing your system.A sizing guide is included to help determine the number of users that can be supported on a specificnumber of servers and configuration.The tests cover the following major functional areas of public access, authentication, andauthorization: The public requests test is focused on Access Gateway as a reverse proxy with caching to helpincrease the speed of your web servers by eliminating any authentication and authorizationpolicy overhead. The authentication requests test is focused on the distributed architecture that provides asecure login to Access Manager. The authorization requests test is focused on the policy evaluation that occurs after the loginhas been completed and before the page is accessed.The test environment includes a cluster of four Identity Servers and four Access Gateways. Thenumber of users and the amount of traffic determine the size of the cluster. Section A.1.1, “Performance, Reliability,

1 Access Manager Performance 7 1Access Manager Performance Section1.1, “Access Gateway Appliance,” on page7 Section1.2, “Access Gateway Service on SLES 12,” on page8 Section1.3, “Access Manager Appliance,” on page9 Section1.4, “Access Gateway Service on Windows,” on page10 Section1.5, “Iden