CA Single Sign-On. Performance Test Report R12
|
|
- Chad Hill
- 6 years ago
- Views:
Transcription
1 CA Single Sign-On Performance Test Report R12
2 Contents CHAPTER 1: OVERVIEW INTRODUCTION SUMMARY METHODOLOGY GLOSSARY CHAPTER 2: TESTING METHOD TEST ENVIRONMENT DATA MODEL CONNECTION PROCESSING SYSTEM PARAMETERS LOAD SIMULATION RESTRICTIONS CHAPTER 3: SCENARIOS SCENARIO 1: DETERMINING THE FORK LIMIT SCENARIO 2: DEMONSTRATE CONNECTION PROCESSING SCENARIO 3: OBSERVING THE RESPONSE TIME SCENARIO 4: THE EFFECT OF A LARGE APPLICATION SCRIPT
3 Chapter 1: Overview Introduction When configuring CA SSO in a customer environment, it is necessary to understand how to maximize throughput, how to minimize response times, and how to ascertain the number simultaneous SSO Clients a system can sustain. This document describes a series of performance tests that can be used to achieve these objectives. With hardware and operating systems changing constantly, it is not possible to recommend particular configurations. The results in this document provide a starting point from which customers can design, test and scope a solution that suits their environment. By configuring the SSO Server environment and then applying a simulated client load, we can exercise or demonstrate the behavior of the SSO Server in various scenarios and configurations. One aspect that is critical to understanding the performance of the SSO Server is an understanding of the connection processing model, which determines how the SSO Server handles a large number of concurrent connections. This is described later. Summary There are a number of settings that you need to understand and determine so that you can optimize your SSO installation. This section is a summary of what you need to understand and how you should determine those settings. The rest of this document explains each of these settings in more detail and guides you through how to determine the optimal value for each setting. Connection processing An understanding of how the SSO Server processes connections is a critical component of determining the parameters which impact performance of the SSO Server. Fork limit The optimum fork limit value for a particular system should be determined empirically by simulating a load on the SSO Server and observing the throughput and response times for various values of the fork limit.
4 Communication Mode The SSO Clients can communicate with the R12 SSO server in two different communication channels. 1. The legacy communication mode (Non-FIPS) and 2. The new mode (FIPS), wherein the communication between different SSO components is FIPS-140 complaint. Here the communication is more secured, requires an SSL handshake between client and Server for each request. It is very important to choose the appropriate mode basing on the requirements. We compare the performance of the R12 SSO Server between these two modes. This comparison helps in making a decision about which communication mode to chose. Methodology A number of tests were performed to test the SSO Server: Scenario 1: Determining the Fork Limit Apply a maximum simulated load, to understand the effect on throughput of changing the fork limit and thus to determine the best default fork limit value. Scenario 2: Demonstrate Connection Processing Show the expected behavior of the system under both heavy and excess loads, demonstrate consistent server behavior under these conditions. Scenario 3: Observing the response time Observe the impact on response times when the number of client connections is varied with a specified number of worker threads. Scenario 4: The effect of a large application script Demonstrate the impact of large application scripts on response time and throughput.
5 Glossary GAL: The Get Application List operation. GLV: The Get Logon Variables operation. Operation: It could be one of these SSO Logon, GAL or GLV operations. PSTD: SSO Server (Policy Server) Token Directory that holds SSO tokens. A token represents a client connection to the server. Server thread: A thread on the SSO Server that is serving requests. Simulated clients: We have used an internal tool that can simulate the operations of any number of SSO Clients from a single machine. SSO Logon: The logon operation, this includes user authentication to the authentication agent followed by user logon to SSO. Thrashing: The behavior of a computer when it fails to operate efficiently because of spending too much of time in switching between tasks. Transaction: A sequence of operations that can be simulated. In our tests, a transaction consisting of one SSO Logon operation, followed by a GAL operation, followed by two GLV operations, with configurable delays after each operation.
6 Chapter 2: Testing Method Test Environment The performance tests described in this document were conducted in a strictly controlled environment. Some tests required only a single server while others were performed using a server farm configuration. We have used the ps-ldap data store and SSO authentication methods for our tests. Single Server Environment A single server environment was used for some of the test cases, such as determining the fork limit for particular hardware. This diagram shows the single server environment set up. The SSO client machine specifications are: Single processor machine Intel hardware 2.4 GHz 1GB Ram Windows XP SP2 or VISTA SP1 The SSO Server host specifications are: Quad processor (Dual Core) Intel hardware 1.86 GHz 4GB Ram Windows 2003 SP2
7 Server Farm Environment A server farm environment was used for some test cases, such as demonstrating connection processing. This diagram shows the server farm configuration set up. The SSO client machine host specifications are: Single processor machine Intel hardware 2.4 GHz 1GB Ram Windows XP SP2 or VISTA SP1 The SSO Server host specifications are: Quad processor (Dual Core) Intel hardware 1.86 GHz 4GB Ram Windows 2003 SP2 Data Model Data Rules This section describes the SSO best practice for the user/application rule relationship. We do not recommend using Application Groups. This is because authorization decisions involving Application Groups are slower than those that use rules directly linked to the resources. It is therefore necessary to minimize the number of authorization rules as there is a clear relationship between the authorization response time and the number of rules in the database.
8 Note: This means that the following rules should be followed: Applications are authorized to user groups Users are assigned to user groups Along with the above data base we have defined another data base in the policy server, wherein the applications are directly assigned to the users (without having the user groups). Sample Data Used The sample data used for these experiments is as follows: Database-1 o users. o 500 user groups. o 100 applications. o Each user belongs to 5 user groups on an average (with a minimum of 1 and a maximum of 100 user groups per user). o Each application is authorized to 5 user groups on an average (with a minimum of 1 and a maximum of 25 user groups per application). Database-2 o users. o 5 applications. o Each user is authorized to all the 5 applications. Connection Processing To understand the performance constraints, it is necessary to understand the way in which the SSO Server handles connections as well as the system parameters which contribute to the performance and scalability behavior. How Connections Are Processed
9 When an SSO Client connects to the SSO Server (by either FIPS or Non-FIPS communication mode), the actions and subsequent response of the server depend on the number of existing connections to the server. The SSO Server handles incoming connections as outlined below: 1. The first connections are accepted and processed immediately. The number of connections is set using the fork limit setting. Each of these connections is allocated to a thread for servicing their requests. 2. Once the fork limit has been reached, subsequent connection requests are added to the receive queue, until it becomes full. 3. Once the receive queue limit has been reached, subsequent connection requests are added to the busy queue. In this case, clients will immediately receive a Server Busy response. As server busy response is sent immediately the busy queue does not usually reach capacity. 4. If the busy queue does reach capacity, the SSO Server is unable to respond to the connection requests. In this case, the operating system directs a number of connections to the TCP/IP queue. 5. If the TCP/IP queue limit has been reached, connection requests will receive a TCP/IP error. One Thread per Connection SSO operates on a one-thread-per-connection model: when an SSO Client makes a connection to the SSO Server, a thread is allocated to that connection. The connection is held open until either the SSO Client or the SSO Server closes the connection. In R12, the SSO Client explicitly closes the connection, once the request is served. Hence for every request the SSO client opens a new connection on the SSO server. If the client does not close the connection after completion of the request, then the server closes it after the server Idle Time out has been reached. Connection Rate The rate at which SSO Clients make connections to the server is the connection rate. The connection rate has two aspects: The sustained connection rate the sustained rate of connection requests that the server can respond to. The instantaneous connection rate the number of connection requests that occur at any one time.
10 The sustained connection rate is the average number of simultaneous connections the server can handle over an extended time period. This is represented by the red line in the preceding graph. The fork limit determines the sustained throughput rate. The underlying system hardware and resources determine the overall system capability. The fork limit should be set to make best use of the system resources. If the fork limit is too small, the system is underutilized. If the fork limit is too large, the system thrashes. The instantaneous connection rate is the connection rate at any instant in time. This is represented by the blue line in the preceding graph. If many connection requests are made, not all of them can be handled instantly. Additional requests may be queued until the server can respond to them. The size of the receive queue affects the system s response to the instantaneous connection rate. Depending on the throughput rate, the receive queue size should be large enough to handle the largest instantaneous connection rate (number of simultaneous connections). However, the user experiences these queued connection requests as delays in SSO Client operations. The result of the Observing response times test can be used to estimate the delays experienced by the users and to properly set timeout settings in the client.
11 System Parameters In order to determine the optimum configuration for system performance, you must understand certain parameters available on the SSO Server and the SSO Client. Communication Mode This parameter defines the mode of communication between the SSO Clients and the R12 SSO server. 1. The legacy communication mode (Non-FIPS) and 2. The new mode (FIPS), wherein the communication between different SSO components is FIPS-complaint. Here the communication is more secured, requires an SSL handshake between client and Server for each request. This parameter also controls the system performance, as the SSL Handshake is a time consuming activity, this result in a drop of performance of the SSO Server in FIPS communication mode compared to the Non-FIPS communication mode. To set the Communication mode, go to the Policy Manager and select Resources, Configuration Resources, Policy Server Settings, Communication, and CommMode. Fork Limit The fork limit parameter determines the number of concurrent threads the SSO Server has to immediately process connections. The greater the fork limit, the more concurrent connections can be handled. However there will be a limit imposed by system resources because the machine can run out of resources if there are too many threads in use. For example, the machine may spend all of its time swapping between threads, or there may be so many threads that little work is done on each thread per unit of time. To set the fork limit, go to the Policy Manager and select Resources, Configuration Resources, Policy Server Settings, Communication, and Forklimit. ForkLimit Analogy: Let s say we have a 10 lane highway (which represents the AC, and Directory Cache and resources). But we only have 1 one toll booth (representing an SSO Fork/Thread) to get to the 10 lane highway. If we have limited toll booths (SSO Fork/Threads) to service the incoming cars (representing SSO Client connections/requests) but we have plenty of lanes (AC, and Directory) just waiting to be used, we have too few toll booths (SSO Forks/Threads) available. We can also explain why too many toll booths (SSO threads) can be a problem. If we had 100 toll booths (SSO Threads) for 10 lanes (AC, and Directory) we would be able to take
12 on 100 cars (SSO Clients) at a time, but they could not pull forward after paying because of all the traffic on the other side (AC, and Directory) are backed up. In this case this could cause traffic jam (overload of AC, and Directory) which slows down the flow of traffic (SSO server). Receive Queue Size The size of this queue is defined by the receive queue size parameter in the SSO Server. If no value is defined on the SSO Server for the receive queue size, the default is 10 multiplied by the fork limit value. Requests in the receive queue will be handled by the server as they are removed from the queue. Depending on the throughput, this will be experienced as a delay in the SSO Client. If the receive queue size is large, connections may be queued on the server waiting to be handled, which will result in the user experiencing a poor server response. If the receive queue size is small, some users will receive a Policy Server unavailable response if their request is further back in the queue. A better outcome may be achieved by increasing the receive queue size, which would result in more connection requests being successfully handled without error messages. The cost is that there may be a longer delay for any response for some of the users, depending on where their requests are in the queue. To set the receive queue size, go to the Policy Manager and select Resources, Configuration Resources, Policy Server Settings, General, ReceiveQueueSize. TCP/IP Queue Size The TCP/IP queue size represents the number of connection requests that the operating system will queue while the SSO Server is unable to respond to requests. The size of this queue can be set in the Policy Manager by the CommListenQueueSize setting. To set the TCP/IP queue size (CommListenQueueSize), go to the Policy Manager and select Resources, Configuration Resources, Policy Server Settings, General, and CommListenQueueSize. Load Simulation We have used an internal tool that can simulate multiple SSO clients by performing a transaction - a sequence of operations - as if they were using the SSO Client. The simulation includes: 1. SSO logon including user authentication and SSO logon 2. Getting application list (GAL) - simulating the SSO Client retrieving a list of applications allocated to a user.
13 3. Getting logon variables (GLV) getting the applications scripts and the user s logon variables corresponding to the applications. The tool can simulate a number of concurrent connections, where each connection performs the configured transaction. This represents a number of users all requesting operations on the SSO Server at the same time. The simulator allows each concurrent connection to perform a number of transactions, with each transaction using a different user. When a user logs on to a workstation using SSO GINA and then runs an application using SSO Client, a typical scenario consists of the following sequence of operations: 1. SSO Logon: The user authenticates to an authentication agent and then logs on to SSO via the SSO GINA. 2. First GLV (Get Logon Variables): The SSO GINA retrieves the Windows logon credentials. The SSO GINA uses these credentials to logon to Windows. 3. GAL (Get Application List): The SSO Client requests and receives the list of applications that the user is authorized to run. 4. Second GLV: The user runs an SSO application and the SSO Client retrieves the logon credentials for that application. For all of the tests below, the tool is configured to simulate a similar sequence of operations. It should be noted that the order of operations as simulated by the tool is different from the preceding sequence. The tool performs the GAL operation before it performs the GLV operations. While the operations are performed in a slightly different order, this is not considered to have any bearing on these tests. The tool simulates the following sequence of operations as an approximation of the scenario described earlier: 1. SSO Logon: User authentication to an authentication agent and logon to SSO via the SSO GINA. 2. Post auth Delay: An SSO GINA application delay after an SSO logon, before the SSO Client requests the application list. 3. GAL (Get Application List): The SSO Client request and reception of the list of applications that the user is authorized to run. 4. Post Applist Delay: An SSO GINA delay after getting the application list before the SSO GINA requests an application s logon credentials. 5. First GLV (Get Logon Variables): SSO GINA retrieval of the Windows logon credentials.
14 6. Extra delay: SSO GINA logon to Windows, Windows load and display of the desktop, SSO Client start up, and the user movement of the mouse ready to click on an SSO application. 7. Second GLV: The user initiating running of an SSO application, and the SSO Client retrieval of the logon credentials for that application. 8. Extra delay: SSO Client log on of user to the application. 9. Delay before close: SSO Client holding the connection open for a period of time. The tool provides measures of: Throughput: transactions per minute Errors: number of errors in operation Response times: minimum, average and maximum times for each operation, that is, SSO Logon, GAL, and each GLV operation. There are two types of GAL operations that can be requested by an SSO Client: 1. Get from cache is when the server gets the application list from the application list cache. This is prompted by one of the following actions: a. The user logs on to SSO after having logged on to SSO at least once previously b. The automatic application list refresh service has been configured to run on the SSO Client and there are no changes to the application list cache on the server. 2. Refresh/recalculation is when the SSO server calculates and caches the application list and returns it to the client. This operation is more time/resource consuming than the get from cache operation. This operation is prompted by one of the following actions: a. The user s application list cache file has been changed on the server b. The user logs onto SSO for the first time ever which means that the cached application list does not yet exist c. The user requests their application list be refreshed using the Refresh button on the SSO Client interface. The tool requests the more expensive refresh/recalculation operation. The tool can be configured so that each thread will execute a configured number of transactions, or so that each thread will execute as many transactions as possible within a fixed time period. These tests use the tool to execute a configured number of transactions.
15 In general, the tests limit the use of the tool to ensure that our Load simulator tool is not a bottleneck in generating the load on the SSO Server. A Dell GX270 host running the simulator with 100 threads at maximum rate averaged 80% CPU usage, reaching 100% occasionally. Where a load of greater than 100 simulated clients was required, a number of machines running the simulator were used. Restrictions These tests were conducted without enabling Session Management. Chapter 3: Scenarios Scenario 1: Determining the Fork Limit Purpose Determine the optimum fork limit setting for the SSO Server. The fork limit is the number of threads on the SSO Server allocated to handle the connections. It is an important factor in the performance of the SSO Server. The number of threads is constrained by the resources available on the server (such as the CPU and memory). The expectation is that the rate of increase in throughput will continue until an optimum level is achieved. At some point, any performance improvement achieved by increasing the number of threads may reduce, due to the number of threads being so large that thrashing occurs. The optimum fork limit value determined in this way will form the basis of the remaining tests. Method To provide a load-simulated scenario, a large number of simulated clients will be used. This load should equal or exceed the fork limit but still be less than the receive queue size value. It should remain consistent to ensure that load characteristics are not a contributing factor of the scenario. To assist simulating maximum load, the delays in our simulator tool are
16 all set to 0. While this is not representative of the operation of the SSO Client application, it is appropriate to consistently maximize the load on the server. This test is performed in a Single Server Environment. Simulation Details Delay after authenticate step: 0 Second Delay after Get application list: 0 Second Number of applications to retrieve: 2 Delay after retrieving application: 0 Second Delay before closing server connection: 0 Second Delay before restarting transaction cycle: 0 Second Simulated clients: 600 Transactions per thread: 10 Policy server configurations Forklimit ReceiveQueueSize 300 (Initial condition) 10*Fork Limit (Default), unless 10*Fork limit is less than simulated clients 1. Run the above scenario and observe the throughput. 2. Increase the Fork limit (and ReceiveQueueSize if required) and repeat. Results We have simulated 600 clients using the tool running on three different machines. The following graphs show how the throughput varies against the fork limit in FIPS and Non-FIPS modes.
17 7500 Throughput Vs ForkLimit (Non-FIPS) Throughput (Logins per min) Forklimit Throughput (600 Clients Simulated)
18 There was a noticeable increase in throughput as the fork limit was increased from 500 to 700. As the fork limit was increased from 700 through to1100, there appears to have been a slight decrease in throughput. The throughput shown above represents the maximum number of transactions per minute that the server can perform. Each transaction is known to consist of four operations: one SSO Logon, one GAL, and two GLVs. The throughput in this environment for the server in FIPS mode with a fork limit of around 800 is approximately 1750 transactions per minute, which are approximately 7000 operations per minute. The throughput in this environment for the server in Non-FIPS mode with a fork limit of around 700 is approximately 7200 transactions per minute, which are approximately 28,800 operations per minute. As we can observe that there is almost 75% hit in the performance of the SSO Server in the FIPS mode compared to that in the Non-FIPS mode. In the FIPS mode, an SSL handshake is done between the client and the server before the request is being served. The SSL handshake is a time consuming activity, which reduces the number of requests served by the SSO server. Hence there is a drop in the SSO Server performance. As we can observe from the graph, the GAL response is almost twice as compared to GLV response. This is because the GAL request involves more operations compared to GLV request.
19 Response Times (sec) Response Times Vs Fork Limit (Non-FIPS) Forklimit Login Response GAL Response GLV Response In Non-FIPS mode, only the Login response is significant, other two GAL, GLV averages are less than a sec. Here there are no SSL handshakes involved, hence the GAL and GLV response times are much smaller than the logon response. In the previous graphs which charts response times, the decreasing SSO Logon Average demonstrates that the connection requests are being queued in the receive queue. At the lower fork limit values, the number of simulated clients is well in excess of the fork limit. A significant component of the longer times for SSO Logon Average represents the average time the request spends in the receive queue. As the fork limit increases, fewer of the requests must wait in the receive queue, therefore the SSO Logon Average is reduced. We have repeated the above test for different number of simulated clients. The following table summarizes the results of our tests. FIPS: Simulated Clients Optimum Fork Limit Throughput
20 Non-FIPS: Simulated Clients Optimum Fork Limit Throughput Any Fork Limit more than the quoted value in the above table for a given simulated number of clients results in a little drop of the Throughput. Conclusions: It should be noted that the simulated load used here (with no delays between operations) is not representative of a realistic load on the SSO Server. The fork limit is not the sole contributing performance factor for the SSO Server. This test is the control case; it allows us to determine the optimum fork limit for a maximum operation load. Setting the Forklimit little higher than the simulated clients results in the best throughput by the system. Recommendations To get the best utilization of the resources, estimate the maximum number of clients that the system can face during the high loads (say X ) and set the Fork limit of the system to a value little higher than X value (For example, X+100 ). To set the fork limit, go to the Policy Manager and select Resources, Configuration Resources, Policy Server Settings, Communication, and Forklimit.
21 Scenario 2: Demonstrate Connection Processing Purpose Demonstrate the connection processing behavior as described in How Connections Are Processed. The queuing implementation allows the SSO Server to, under different circumstances, immediately handle requests, queue requests, or respond with a Server is unavailable response. The server handles all immediate or queued requests. After such a load recedes and the backlog is handled, the server continues to operate as normal. This test is divided into a number of subtests. Subtest 1. Simulated clients <= fork limit All requests should be served immediately. 2. Fork limit < simulated clients < (fork limit + receive queue size) All requests should be served, but due to queuing, the response time will increase. 3. (Fork limit + receive queue size) < simulated clients The number of requests will exceed the queue, so some simulated clients should receive a Server is unavailable response from the SSO Server. 4. Recovery after Server is unavailable responses The SSO Server responds with errors whilst its connections are consumed, but after the backlog is handled the SSO Server continues handling connection requests.
22 Method Test parameters are set as shown below. The number of simulated clients is determined by the subtest. This test is performed in a Single Server Environment. Simulation Details Delay after authenticate step: 0 Second Delay after Get application list: 0 Second Number of applications to retrieve: 2 Delay after retrieving application: 0 Second Delay before closing server connection: 0 Second Delay before restarting transaction cycle: 0 Second Simulated clients: Determined by the subtest Transactions per thread: 1000 divided over all the simulated clients. Policy server configurations Forklimit ReceiveQueueSize SendBusyQueueSize ServerIdleTimeout 2 (Low enough to exceed queues easily) 10*Fork Limit (Default). 20 (Default) 60 seconds (Default) Subtest 1: Simulated clients < fork limit 1. Configure simulated clients as follows Simulated clients Simulated clients <= fork limit. We used Run the scenario and observe the number of busy threads, receive queue size, and the number of errors. Subtest 2: Fork limit < simulated clients < (fork limit + receive queue size) 1. Configure simulated clients as follows: Simulated clients fork limit < simulated clients < (fork limit + receive queue size). We used Run the scenario and observe as before. Subtest 3: (fork limit + receive queue size) < simulated clients 1. Configure simulated clients as follows: Simulated clients (fork limit + receive queue size) < simulated clients. We used Run the scenario and observe as before. Subtest 4: Recovery after Server is unavailable responses 1. Configure the SSO Server as follows: Forklimit 10 ReceiveQueueSize 10 SendBusyQueueSize 20 (Default) ServerIdleTimeout 60 seconds (Default)
23 2. Configure the simulation on machine-1 with the simulated clients to occupy the fork limit and the receive queue of the server, as follows: Simulation Details Post auth Delay 0 seconds Post Applist Delay 0 seconds Extra delay 0 seconds Delay before close 55 seconds Simulated clients: (fork limit + receive queue size) Transactions per thread 2 3. Configure a second machine with the simulated clients to send requests while the receive queue is full, as follows: Simulation Details Post auth Delay 0 seconds Post Applist Delay 0 seconds Extra delay 0 seconds Delay before close 0 seconds Simulated clients: (< SendBusyQueueSize) Transactions per thread 5 4. Run the simulator on the first machine. After approximately 10 seconds (when the requests on the first host have reached Delay before close ) run the simulator on the second host. Results
24 The results above are for: Subtest 1: Simulated clients < fork limit (with 2 simulated clients)
25 Subtest 2: Fork limit < simulated clients < (fork limit + receive queue size) (with 7 simulated clients) Subtest 3: (fork limit + receive queue size) < simulated clients (with 30 simulated clients) When the number of simulated clients was less than or equal to the fork limit, all requests were successfully handled. When the number of simulated clients was greater than the fork limit and less than the receive queue size, delays were experienced in the responses as expected, after which the requests were successfully handled. Server is unavailable responses were observed when the number of simulated clients exceeded fork limit + receive queue size. In Subtest 3, the busy threads and receive queue numbers as monitored in Windows Performance Monitor were as expected - they reached the maximum values specified. In Subtest 4, all transactions for the simulated clients from the first machine were successfully completed, including those which occurred after the Server is unavailable responses were sent by the server. Conclusions In this test, the response time for the SSO Logon operation varied depending on the number of connection requests in the receive queue. With the number of connection requests so much greater than the fork limit, the response time at lower fork limit values was large because so many connection requests were waiting in the receive queue. When the number of incoming connections exceeds the fork limit, the request will wait in the receive queue for a connection. When the receive queue is exceeded, the SSO Client receives a Server is unavailable response, reported to the user as the communication error: Policy Server unavailable. Recommendations Understanding connection processing is necessary to determine the expected user experience. Setting a low receive queue size means that users may receive a Server is unavailable response, which provides useful feedback to the user. Setting a high receive queue size means that the users may experience lengthy delays when they make requests. If the user should not get the Server unavailable error, we need to put a value for the ReceiveQueueSize that is more than number of simulated clients fork limit. If the user should get a proper feedback on his request to the server then we need to put a value for the ReceiveQueueSize that is less than the Fork limit.
26 To set the values for the ReceiveQueueSize and fork limit please refer to the System parameters section in the chapter 2. Scenario 3: Observing the response time Purpose Observe the response time experienced by the user when the server is servicing requests under load. While the server throughput is influenced by the fork limit, the response time experienced by the user of the SSO Client can vary. The test allows us to understand the response time that would be experienced by the user under situations of load. In this test the fork limit is fixed and the simulated client load is varied. Measurements are taken of the delay between the time the request is made and the time it is handled. The expectation is that as the number of requests in the queue increase, the response time will increase until the delay experienced by the user becomes unacceptable. This test will assist in determining the receive queue size and client response timeout. If too many requests are queued, the response time for late arrivals in the queue will be unacceptably high. The client response timeout can be used to cause the client to abort the transaction and display a failure to the user. Method This test is performed in a Server Farm Environment.
27 Simulation Details Delay after authenticate step: 0 Second Delay after Get application list: 0 Second Number of applications to retrieve: 2 Delay after retrieving application: 0 Second Delay before closing server connection: 0 Second Delay before restarting transaction cycle: 0 Second Simulated clients: < (Fork Limit x Servers) (Initial condition) Transactions per thread: 5000 divided over all the simulated clients. Policy server configurations Forklimit ReceiveQueueSize ServerIdleTimeout 50 (Initial condition) 10*Fork Limit (Default). 60 seconds (Default) Results 1. Run the scenario and observe the throughput and response times. 2. Increase the simulated clients and repeat. 0.9 Simulated Clients Vs Response Times (Non-FIPS) Response Time (Secs) Logon Response GAL Response GLV Response Simulated Clients
28 Three hosts were used in this test to simulate the SSO Clients; the values above present the overall number of simulated clients. The SSO Logon Average response time was approximately linear in increase after the number of simulated clients exceeded the fork limit. The SSO Logon Average includes both the time taken to authenticate and the time waiting in the receive queue to complete the logon process with the SSO Server. Conclusions The response times increase as the number of simulated clients is increased and is simply a result of the requests waiting in the receive queue. As the number of concurrent users increases beyond the fork limit, the response times for those users will also increase as their requests are queued. These requests can only be handled once the previous connections have been closed, releasing the server threads to service the receive queue. The delay experienced by the user is a result of the queuing; the more queued requests the longer the delays. The results mentioned above can be used estimate the response times based on the estimated number of simultaneous clients, which in turn will help in adjusting the timeout settings in the client.ini file. For example, if the server can handle 1000 connection requests per minute and the receive queue contains 500 connection requests; the connection requests at the end of the
29 queue may experience a delay of 30 seconds before they are handled. If this delay is considered unacceptable, the client response Timeouts in the SSO Client can be set so that the request is cancelled and the user is shown an appropriate message. Recommendations If the user should not get the Server unavailable error, we need to put a value for the ReceiveQueueSize that is more than number of simulated clients fork limit. If the user should get a proper feedback on his request to the server then we need to put a value for the ReceiveQueueSize that is less than the Fork limit. To set the values for the ReceiveQueueSize and fork limit please refer to the System parameters section in the chapter 2. Scenario 4: The effect of a large application script Purpose Demonstrate the effect of the size of the application script on the response time and throughput of the server. Method This test is performed in a Single Server Environment. Simulation Details Delay after authenticate step: 0 Second Delay after Get application list: 0 Second Number of applications to retrieve: 2 Delay after retrieving application: 0 Second Delay before closing server connection: 0 Second Delay before restarting transaction cycle: 0 Second Simulated clients: 50 Transactions per thread: 2000 divided over all the simulated clients.
30 Policy server configurations Forklimit 50 ReceiveQueueSize 10*Fork Limit (Default). ServerIdleTimeout 60 seconds (Default) Script Size 0 KB (Initial Condition) 1. Run the scenario and observe the throughput and response time. 2. Run the scenario with increased script sizes and compare the results. Results The following graph shows the effect of the size of the application script on the response time of the SSO server in FIPS and Non-FIPS modes.
31 As we can see the response times are getting affected with the increase in the script file size. The reason is that, the script for the application is downloaded as part of the Login
32 variables; hence the time to download the script will also be part of the response time. As the size of the file increases the download time affects the response times. The following graph shows the effect of the size of the application script on the throughput of the SSO server in FIPS and Non-FIPS modes.
33 Conclusion Increasing the script size causes a little decrease to the throughput and an increase in the response time. Recommendations The script file size has a little affect on the system performance.
Configuring Avaya one-x Agent 2.5 Patch 2 with Citrix XenApp TM 5.0 on Microsoft Windows 2003 (32-bit) Server Issue 1.0
Avaya Solution & Interoperability Test Lab Configuring Avaya one-x Agent 2.5 Patch 2 with Citrix XenApp TM 5.0 on Microsoft Windows 2003 (32-bit) Server Issue 1.0 Abstract This Application Note describes
More information10 MONITORING AND OPTIMIZING
MONITORING AND OPTIMIZING.1 Introduction Objectives.2 Windows XP Task Manager.2.1 Monitor Running Programs.2.2 Monitor Processes.2.3 Monitor System Performance.2.4 Monitor Networking.2.5 Monitor Users.3
More informationSCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT
SCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT QlikView Technical Brief February 2012 qlikview.com Introduction When it comes to the enterprise Business Discovery environments, the ability of the
More informationLotus Sametime 3.x for iseries. Performance and Scaling
Lotus Sametime 3.x for iseries Performance and Scaling Contents Introduction... 1 Sametime Workloads... 2 Instant messaging and awareness.. 3 emeeting (Data only)... 4 emeeting (Data plus A/V)... 8 Sametime
More informationMobiLink Performance. A whitepaper from ianywhere Solutions, Inc., a subsidiary of Sybase, Inc.
MobiLink Performance A whitepaper from ianywhere Solutions, Inc., a subsidiary of Sybase, Inc. Contents Executive summary 2 Introduction 3 What are the time-consuming steps in MobiLink synchronization?
More informationParallels Virtuozzo Containers
Parallels Virtuozzo Containers White Paper Parallels Virtuozzo Containers for Windows Capacity and Scaling www.parallels.com Version 1.0 Table of Contents Introduction... 3 Resources and bottlenecks...
More informationTest Methodology We conducted tests by adding load and measuring the performance of the environment components:
Scalability Considerations for Using the XenApp and XenDesktop Service Local Host Cache Feature with Citrix Cloud Connector Author: Jahed Iqbal Overview The local host cache feature in the XenApp and XenDesktop
More informationUnderstanding the performance of an X user environment
Understanding the performance of an X550 11-user environment Overview NComputing s desktop virtualization technology enables significantly lower computing costs by letting multiple users share a single
More informationInstalling and Configuring VMware Identity Manager Connector (Windows) OCT 2018 VMware Identity Manager VMware Identity Manager 3.
Installing and Configuring VMware Identity Manager Connector 2018.8.1.0 (Windows) OCT 2018 VMware Identity Manager VMware Identity Manager 3.3 You can find the most up-to-date technical documentation on
More information12d Synergy Requirements
This document outlines the requirements for a 12d Synergy implementation. The server requirements may differ based on the number of users. Operating below these minimum requirements will put you in an
More informationLesson 2: Using the Performance Console
Lesson 2 Lesson 2: Using the Performance Console Using the Performance Console 19-13 Windows XP Professional provides two tools for monitoring resource usage: the System Monitor snap-in and the Performance
More informationTerminal Services Scalability Study
Terminal Services Scalability Study Part 1 The Effect of CPS 4.0 Microsoft Windows Terminal Services Citrix Presentation Server 4.0 June 2007 Table of Contents 1 Executive summary 3 2 Introduction 4 2.1
More informationInstallation Guide. EventTracker Enterprise. Install Guide Centre Park Drive Publication Date: Aug 03, U.S. Toll Free:
EventTracker Enterprise Install Guide 8815 Centre Park Drive Publication Date: Aug 03, 2010 Columbia MD 21045 U.S. Toll Free: 877.333.1433 Abstract The purpose of this document is to help users install
More informationBlackBerry Enterprise Server for IBM Lotus Domino Version: 5.0. Administration Guide
BlackBerry Enterprise Server for IBM Lotus Domino Version: 5.0 Administration Guide SWDT487521-636611-0528041049-001 Contents 1 Overview: BlackBerry Enterprise Server... 21 Getting started in your BlackBerry
More informationDIRECTORY INTEGRATION: USING ACTIVE DIRECTORY FOR AUTHENTICATION. Gabriella Davis The Turtle Partnership
DIRECTORY INTEGRATION: USING ACTIVE DIRECTORY FOR AUTHENTICATION Gabriella Davis The Turtle Partnership In This Session Review possible use cases for multiple directories Understand security implications
More informationPerformance Characterization of the Dell Flexible Computing On-Demand Desktop Streaming Solution
Performance Characterization of the Dell Flexible Computing On-Demand Desktop Streaming Solution Product Group Dell White Paper February 28 Contents Contents Introduction... 3 Solution Components... 4
More informationBenchmark Performance Results for Pervasive PSQL v11. A Pervasive PSQL White Paper September 2010
Benchmark Performance Results for Pervasive PSQL v11 A Pervasive PSQL White Paper September 2010 Table of Contents Executive Summary... 3 Impact Of New Hardware Architecture On Applications... 3 The Design
More informationEstimate performance and capacity requirements for InfoPath Forms Services 2010
Estimate performance and capacity requirements for InfoPath Forms Services 2010 This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site
More informationNetegrity SiteMinder 4.51 AuthMark Performance Details
Page 1 of 12 Netegrity SiteMinder 4.51 AuthMark Performance Details By Bruce Weiner (PDF version, 96 KB) Contents Executive Summary Test Methodology iload MVP AuthMark Result Analysis Server Hardware Server
More informationSYNTHESYS.NET PORTAL WEB BROWSER
SYNTHESYS.NET PORTAL WEB BROWSER Synthesys.Net Portal Taking Calls 1 All rights reserved The contents of this documentation (and other documentation and training materials provided), is the property of
More informationPerformance Benchmark and Capacity Planning. Version: 7.3
Performance Benchmark and Capacity Planning Version: 7.3 Copyright 215 Intellicus Technologies This document and its content is copyrighted material of Intellicus Technologies. The content may not be copied
More informationIntroduction. CS3026 Operating Systems Lecture 01
Introduction CS3026 Operating Systems Lecture 01 One or more CPUs Device controllers (I/O modules) Memory Bus Operating system? Computer System What is an Operating System An Operating System is a program
More informationKey Performance Metrics Exposed in EdgeSight for XenApp 5.0 and EdgeSight for Endpoints 5.0
White Paper Key Performance Metrics Exposed in EdgeSight for XenApp 5.0 and EdgeSight for Endpoints 5.0 EdgeSight Archtectural Overview EdgeSight for XenApp is implemented as an agent based solution for
More informationScalability Testing with Login VSI v16.2. White Paper Parallels Remote Application Server 2018
Scalability Testing with Login VSI v16.2 White Paper Parallels Remote Application Server 2018 Table of Contents Scalability... 3 Testing the Scalability of Parallels RAS... 3 Configurations for Scalability
More informationArcGIS Server Performance and Scalability : Optimizing GIS Services
Esri International User Conference San Diego, CA Technical Workshops July 12, 2011 ArcGIS Server Performance and Scalability : Optimizing GIS Services David Cordes, Eric Miller Poll the Audience: Role
More informationMonitoring Citrix XenDesktop Director
Monitoring Citrix XenDesktop Director eg Enterprise v6.0 Restricted Rights Legend The information contained in this document is confidential and subject to change without notice. No part of this document
More informationSecuring VSPEX VMware View 5.1 End- User Computing Solutions with RSA
Design Guide Securing VSPEX VMware View 5.1 End- User Computing Solutions with RSA VMware vsphere 5.1 for up to 2000 Virtual Desktops EMC VSPEX Abstract This guide describes required components and a configuration
More informationVMware View Upgrade Guide
View 4.0 View Manager 4.0 View Composer 2.0 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for
More informationThe Hardware Realities of Virtualization
Quad-Core AMD Opteron Processors with AMD Virtualization (AMD-V ) Deliver Increased Scalability and Performance for Virtualized Citrix XenApp on XenServer. Virtualization is becoming a standard method
More informationNetegrity SiteMinder 4.61 with Microsoft Active Directory AuthMark Performance Details
Page 1 of 16 Netegrity SiteMinder 4.61 with Microsoft Active Directory AuthMark Performance Details By Bruce Weiner (PDF version, 131 KB) April 18, 2002 Contents Executive Summary Login Results Extranet
More informationMobiLink 10 Performance. A whitepaper from Sybase ianywhere. Author: Graham Hurst. Date: March 2009
MobiLink 10 Performance A whitepaper from Sybase ianywhere Author: Graham Hurst Date: March 2009 This whitepaper was written in the context of SQL Anywhere 10. However, its content may be applicable to
More informationSystem recommendations for version 17.1
System recommendations for version 17.1 This article contains information about recommended hardware resources and network environments for version 17.1 of Sage 300 Construction and Real Estate. NOTE:
More informationTechnical and Architectural Overview
100% Web-Based Time & Labor Management Technical and Architectural Overview Copyright 2007 Time America 15990 N. Greenway-Hayden Loop Suite D-500, Scottsdale, AZ (800) 227-9766 www.timeamerica.com Table
More informationJetico Central Manager. Administrator Guide
Jetico Central Manager Administrator Guide Introduction Deployment, updating and control of client software can be a time consuming and expensive task for companies and organizations because of the number
More informationWHITE PAPER: BEST PRACTICES. Sizing and Scalability Recommendations for Symantec Endpoint Protection. Symantec Enterprise Security Solutions Group
WHITE PAPER: BEST PRACTICES Sizing and Scalability Recommendations for Symantec Rev 2.2 Symantec Enterprise Security Solutions Group White Paper: Symantec Best Practices Contents Introduction... 4 The
More informationMicrosoft Office SharePoint Server 2007
Microsoft Office SharePoint Server 2007 Enabled by EMC Celerra Unified Storage and Microsoft Hyper-V Reference Architecture Copyright 2010 EMC Corporation. All rights reserved. Published May, 2010 EMC
More informationEstimate performance and capacity requirements for Access Services
Estimate performance and capacity requirements for Access Services This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references,
More informationAdaptec MaxIQ SSD Cache Performance Solution for Web Server Environments Analysis
Adaptec MaxIQ SSD Cache Performance Solution for Web Server Environments Analysis September 22, 2009 Page 1 of 7 Introduction Adaptec has requested an evaluation of the performance of the Adaptec MaxIQ
More informationMicrosoft Windows GINA login
Microsoft Windows GINA login Contents 1 Introduction 2 Prerequisites 3 Baseline 4 Architecture 5 Swivel Configuration 5.1 Configure a Swivel Agent 5.2 Create a Third Party Authentication 6 Terminal Services
More informationEntuity Network Monitoring and Analytics 10.5 Server Sizing Guide
Entuity Network Monitoring and Analytics 10.5 Server Sizing Guide Table of Contents 1 Introduction 3 2 Server Performance 3 2.1 Choosing a Server... 3 2.2 Supported Server Operating Systems for ENMA 10.5...
More informationvcloud Automation Center Reference Architecture vcloud Automation Center 5.2
vcloud Automation Center Reference Architecture vcloud Automation Center 5.2 This document supports the version of each product listed and supports all subsequent versions until the document is replaced
More informationAdministering View Cloud Pod Architecture. VMware Horizon 7 7.0
Administering View Cloud Pod Architecture VMware Horizon 7 7.0 You can find the most up-to-date technical documentation on the VMware Web site at: https://docs.vmware.com/ The VMware Web site also provides
More informationOptimizing RDM Server Performance
TECHNICAL WHITE PAPER Optimizing RDM Server Performance A Raima Inc. Technical Whitepaper Published: August, 2008 Author: Paul Johnson Director of Marketing Copyright: Raima Inc., All rights reserved Abstract
More informationAutodesk Revit Structure 2012 System Requirements and Recommendations. Minimum: Entry-level configuration. Operating System Microsoft Windows 7 32-bit
Autodesk Revit Structure 2012 System s and Recommendations Minimum: Entry-level configuration Operating System Microsoft Windows 7 32-bit Microsoft Windows Vista 32-bit (SP2 or later) Business Microsoft
More informationPrint Audit 6. Print Audit 6 Documentation Apr :07. Version: Date:
Print Audit 6 Version: Date: 37 21-Apr-2015 23:07 Table of Contents Browse Documents:..................................................... 3 Database Documentation.................................................
More informationJetico Central Manager Administrator Guide
Jetico Central Manager Administrator Guide Introduction Deployment, updating and control of client software can be a time consuming and expensive task for companies and organizations because of the number
More informationPaperVision Message Manager. User Guide. PaperVision Message Manager Release 71
PaperVision Message Manager User Guide PaperVision Message Manager Release 71 June 2010 Information in this document is subject to change without notice and does not represent a commitment on the part
More informationBy Citrix Consulting. Citrix Systems, Inc.
Microsoft Office 2003 Application Scalability Analysis By Citrix Consulting Citrix Systems, Inc. Notice The information in this publication is subject to change without notice. THIS PUBLICATION IS PROVIDED
More informationAMD: WebBench Virtualization Performance Study
March 2005 www.veritest.com info@veritest.com AMD: WebBench Virtualization Performance Study Test report prepared under contract from Advanced Micro Devices, Inc. Executive summary Advanced Micro Devices,
More information1.0. Quest Enterprise Reporter Discovery Manager USER GUIDE
1.0 Quest Enterprise Reporter Discovery Manager USER GUIDE 2012 Quest Software. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide
More informationFull Text Search Agent Throughput
Full Text Search Agent Throughput Best Practices Guide Perceptive Content Version: 7.0.x Written by: Product Knowledge, R&D Date: December 2014 2014 Perceptive Software. All rights reserved Perceptive
More informationSharePoint Server 2010 Capacity Management for Web Content Management Deployments
SharePoint Server 2010 Capacity Management for Web Content Management Deployments This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web
More informationDistributed OrcaFlex. 1. Introduction. 2. What s New. Distributed OrcaFlex
1. Introduction is a suite of programs that enables a collection of networked, OrcaFlex licensed, computers to run OrcaFlex jobs as background tasks using spare processor time. consists of four separate
More informationParallels Remote Application Server. Scalability Testing with Login VSI
Parallels Remote Application Server Scalability Testing with Login VSI Contents Introduction... 3 Scalability... 4 Testing the Scalability of Parallels RAS... 4 Configurations for Scalability Testing...
More informationMarkLogic Server. Monitoring MarkLogic Guide. MarkLogic 8 February, Copyright 2015 MarkLogic Corporation. All rights reserved.
Monitoring MarkLogic Guide 1 MarkLogic 8 February, 2015 Last Revised: 8.0-1, February, 2015 Copyright 2015 MarkLogic Corporation. All rights reserved. Table of Contents Table of Contents Monitoring MarkLogic
More informationPerformance and Optimization Issues in Multicore Computing
Performance and Optimization Issues in Multicore Computing Minsoo Ryu Department of Computer Science and Engineering 2 Multicore Computing Challenges It is not easy to develop an efficient multicore program
More informationIBM Tivoli Storage Manager for AIX Version Installation Guide IBM
IBM Tivoli Storage Manager for AIX Version 7.1.3 Installation Guide IBM IBM Tivoli Storage Manager for AIX Version 7.1.3 Installation Guide IBM Note: Before you use this information and the product it
More informationRightNow May 08 Workstation Specifications
RightNow May 08 Workstation Specifications To maximize the performance of RightNow May 08 staff members and customers, we recommend the following workstation hardware configurations, operating systems,
More informationdocalpha Installation Guide
ARTSYL DOCALPHA INSTALLATION GUIDE 1. docalpha Architecture Overview... 2 1.1. docalpha Server Components... 4 1.2. docalpha Production Environment Stations Overview... 4 1.3. docalpha Setup & Administration
More informationiload MVP is a general-purpose, script-driven capacity planning, benchmarking, and regression testing tool. The major components of iload MVP are:
Oblix NetPoint 4.0 AuthMark Performance Details By Bruce Weiner (PDF version, 410 KB) October 18, 2000 Contents Executive Summary Test Methodology iload MVP AuthMark Result Analysis Server Hardware Server
More informationUser Guide AppAnywhere
User Guide AppAnywhere Spectra AppAnywhere product range is the greatest offering of the world market today! It is a powerful and the easiest way to publish any of your Windows application on a LAN or
More informationASN Configuration Best Practices
ASN Configuration Best Practices Managed machine Generally used CPUs and RAM amounts are enough for the managed machine: CPU still allows us to read and write data faster than real IO subsystem allows.
More informationOne Solution. training guide. Getting started with Clarity Professional v5
Marketing Sales One Solution Website training guide Orders Getting started with Clarity Professional v5 Contents - Introduction - Minimum system requirements - Downloading and installing v5 - New licensing
More informationFour-Socket Server Consolidation Using SQL Server 2008
Four-Socket Server Consolidation Using SQL Server 28 A Dell Technical White Paper Authors Raghunatha M Leena Basanthi K Executive Summary Businesses of all sizes often face challenges with legacy hardware
More informationOracle Enterprise Manager. 1 Before You Install. System Monitoring Plug-in for Oracle Unified Directory User's Guide Release 1.0
Oracle Enterprise Manager System Monitoring Plug-in for Oracle Unified Directory User's Guide Release 1.0 E24476-01 October 2011 The System Monitoring Plug-In for Oracle Unified Directory extends Oracle
More informationMarkLogic Server. Monitoring MarkLogic Guide. MarkLogic 5 October, Copyright 2012 MarkLogic Corporation. All rights reserved.
Monitoring MarkLogic Guide 1 MarkLogic 5 October, 2011 Last Revised: 5.0-3, March, 2012 Copyright 2012 MarkLogic Corporation. All rights reserved. 1.0 Monitoring MarkLogic Server...4 1.1 Overview...4 1.2
More informationCreating and Managing a Content Server Cluster
CHAPTER 10 This chapter describes the main features, system requirements, setup, and management of a Cisco TelePresence Content Server (TCS) cluster. To a user, a Content Server Cluster behaves exactly
More informationSage 300 People & Web Self Service Technical Information & System Requirements
Sage 300 People & Web Self Service Technical Information & System Requirements Sage 300 People Architecture The Sage 300 People application is a 2-tier application with the program and database residing
More informationUser Manual. Admin Report Kit for IIS 7 (ARKIIS)
User Manual Admin Report Kit for IIS 7 (ARKIIS) Table of Contents 1 Admin Report Kit for IIS 7... 1 1.1 About ARKIIS... 1 1.2 Who can Use ARKIIS?... 1 1.3 System requirements... 2 1.4 Technical Support...
More informationC. Reporting Services Server Enter the Web Service URL for your Report Server site.
B I Z I N S I G H T 5. 0. 3 4 Release Notes The 5.0.34 release of BizInsight contains many updates and improvements. This document provides information on the changes and special instructions where needed
More informationResource Containers. A new facility for resource management in server systems. Presented by Uday Ananth. G. Banga, P. Druschel, J. C.
Resource Containers A new facility for resource management in server systems G. Banga, P. Druschel, J. C. Mogul OSDI 1999 Presented by Uday Ananth Lessons in history.. Web servers have become predominantly
More informationImpact of Dell FlexMem Bridge on Microsoft SQL Server Database Performance
Impact of Dell FlexMem Bridge on Microsoft SQL Server Database Performance A Dell Technical White Paper Dell Database Solutions Engineering Jisha J Leena Basanthi October 2010 THIS WHITE PAPER IS FOR INFORMATIONAL
More informationComparison of Storage Protocol Performance ESX Server 3.5
Performance Study Comparison of Storage Protocol Performance ESX Server 3.5 This study provides performance comparisons of various storage connection options available to VMware ESX Server. We used the
More informationSecure Login for SAP Single Sign-On Sizing Guide
PUBLIC SAP Single Sign-On Document Version: 1.1 2018-07-31 Secure Login for SAP Single Sign-On 3.0 - Sizing Guide 2018 SAP SE or an SAP affiliate company. All rights reserved. THE BEST RUN Content 1 Introduction....3
More informationRequirements and Dependencies
CHAPTER 2 You can install and use Security Manager as a standalone product or in combination with several other Cisco Security Management Suite applications, including optional applications that you can
More informationPROMENU WEB ACCESS GUIDE
Business Office 1150 rue Levis, Suite 201 Terrebonne, QC, J6W 5S6 Toll-free : 866.471.2828 Phone : 450.471.2828 Fax : 450.824.0828 Head Office 10 boulevard de Mortagne, Suite 200 Boucherville, QC, J4B
More informationInstalling and Configuring Citrix XenApp 6.5 (Part 1)
Installing and Configuring Citrix XenApp 6.5 (Part 1) Introduction The first part of this series describes the installation steps of the first server (which will create the XenApp environment) and the
More informationEnterprise print management in VMware Horizon
Enterprise print management in VMware Horizon Introduction: Embracing and Extending VMware Horizon Tricerat Simplify Printing enhances the capabilities of VMware Horizon environments by enabling reliable
More informationConsolidating OLTP Workloads on Dell PowerEdge R th generation Servers
Consolidating OLTP Workloads on Dell PowerEdge R720 12 th generation Servers B Balamurugan Phani MV Dell Database Solutions Engineering March 2012 This document is for informational purposes only and may
More informationW H I T E P A P E R. Comparison of Storage Protocol Performance in VMware vsphere 4
W H I T E P A P E R Comparison of Storage Protocol Performance in VMware vsphere 4 Table of Contents Introduction................................................................... 3 Executive Summary............................................................
More informationIncreasing Performance for PowerCenter Sessions that Use Partitions
Increasing Performance for PowerCenter Sessions that Use Partitions 1993-2015 Informatica LLC. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying,
More informationIBM Tivoli Storage Manager for Windows Version Installation Guide IBM
IBM Tivoli Storage Manager for Windows Version 7.1.8 Installation Guide IBM IBM Tivoli Storage Manager for Windows Version 7.1.8 Installation Guide IBM Note: Before you use this information and the product
More informationSpecifying Storage Servers for IP security applications
Specifying Storage Servers for IP security applications The migration of security systems from analogue to digital IP based solutions has created a large demand for storage servers high performance PCs
More informationAdministering Cloud Pod Architecture in Horizon 7. Modified on 26 JUL 2017 VMware Horizon 7 7.2
Administering Cloud Pod Architecture in Horizon 7 Modified on 26 JUL 2017 VMware Horizon 7 7.2 Administering Cloud Pod Architecture in Horizon 7 You can find the most up-to-date technical documentation
More informationConfiguring Avaya one-x Agent 2.0 R2 with Citrix XenApp TM on Microsoft Windows 2003 (32-bit) Server Issue 1.0
Avaya Solution Interoperability Test Lab Configuring Avaya one-x Agent 2.0 R2 with Citrix XenApp TM on Microsoft Windows 2003 (32-bit) Server Issue 1.0 Abstract This Application Note describes the configuration,
More informationConfiguring the Oracle Network Environment. Copyright 2009, Oracle. All rights reserved.
Configuring the Oracle Network Environment Objectives After completing this lesson, you should be able to: Use Enterprise Manager to: Create additional listeners Create Oracle Net Service aliases Configure
More informationServer Specifications
Requirements Server s It is highly recommended that MS Exchange does not run on the same server as Practice Evolve. Server Minimum Minimum spec. is influenced by choice of operating system and by number
More informationSage 300 ERP. Compatibility Guide Version Revised: Oct 1, Version 6.0 Compatibility Guide i
Sage 300 ERP Compatibility Guide Version 2012 Revised: Oct 1, 2012 Version 6.0 Compatibility Guide i Overview 2 Sage ERP Accpac Contents Overview... 1 Version 2012 Compatibility... 2 All Environments...
More informationPerceptive Matching Engine
Perceptive Matching Engine Advanced Design and Setup Guide Version: 1.0.x Written by: Product Development, R&D Date: January 2018 2018 Hyland Software, Inc. and its affiliates. Table of Contents Overview...
More informationNew in this Release...3 New in Pointsec Media Encryption New in this Release of Pointsec Media Encryption - MI Client...4
Release Notes Pointsec Media Encryption - MI Client 2.6 Version B Copyright Pointsec Mobile Technologies AB, 2007, a Check Point Software Techonologies Ltd. company. For full documentation, please see
More informationCS 344/444 Computer Network Fundamentals Final Exam Solutions Spring 2007
CS 344/444 Computer Network Fundamentals Final Exam Solutions Spring 2007 Question 344 Points 444 Points Score 1 10 10 2 10 10 3 20 20 4 20 10 5 20 20 6 20 10 7-20 Total: 100 100 Instructions: 1. Question
More informationIBM Lotus Notes 8.5 on Citrix XenApp 4.5: A scalability analysis
IBM Lotus Notes 8.5 on Citrix XenApp 4.5: A scalability analysis Brian Gallagher IBM Software Group, Lotus Software Manager, Lotus Notes and Domino System Test Westford, MA, USA Gary Denner IBM Software
More informationLog Server Configuration Utility
Email Log Server Configuration Utility Email Log Server is the component that receives log records and processes them into the Log Database. During installation, you configure certain aspects of Log Server
More informationARTSYL DOCALPHA INSTALLATION GUIDE
ARTSYL DOCALPHA INSTALLATION GUIDE 1. docalpha Architecture Overview... 2 1.1. docalpha Server Components... 4 1.2. docalpha Production Environment Stations Overview... 4 1.3. docalpha Setup & Administration
More informationVirtualizing Agilent OpenLAB CDS EZChrom Edition with VMware
Virtualizing Agilent OpenLAB CDS EZChrom Edition with VMware Technical Overview Abstract This technical overview describes the considerations, recommended configurations, and host server requirements when
More informationAdministering Cloud Pod Architecture in Horizon 7. VMware Horizon 7 7.1
Administering Cloud Pod Architecture in Horizon 7 VMware Horizon 7 7.1 Administering Cloud Pod Architecture in Horizon 7 You can find the most up-to-date technical documentation on the VMware Web site
More informationConsulting Solutions WHITE PAPER Citrix XenDesktop XenApp 6.x Planning Guide: Virtualization Best Practices
Consulting Solutions WHITE PAPER Citrix XenDesktop XenApp 6.x Planning Guide: Virtualization Best Practices www.citrix.com Table of Contents Overview... 3 Scalability... 3 Guidelines... 4 Operations...
More informationAdept 8/8.1 System Requirements
Adept 8/8.1 System Requirements Synergis Software 200 Kelly Road, Quakertown, PA 18951 +1 215.529.9900, 800.836.5440 www.synergissoftware.com Adept 8 System Requirements This document provides detailed
More informationIBM Tivoli Storage Manager for HP-UX Version Installation Guide IBM
IBM Tivoli Storage Manager for HP-UX Version 7.1.4 Installation Guide IBM IBM Tivoli Storage Manager for HP-UX Version 7.1.4 Installation Guide IBM Note: Before you use this information and the product
More informationCIMERA ARCHITECTURE. Release 4.2.x
CIMERA ARCHITECTURE Release 4.2.x Version 1.0, 13-May 2015 Gwyn Carwardine, Jon Bentley gwyn.carwardine@propelsystems.com jon.bentley@propelsystems.com Propel Systems, 2015 Cimera Architecture R4.2.x Page
More information