Technical Notes

This technical note uses several performance characteristics of Verastream Host Integrator (VHI) Session Server to provide a basic understanding of VHI sizing techniques in Windows and Linux/UNIX environments.

This document covers the following topics:

The session server plays a central role in VHI installations. This information provides a working knowledge of how the session server responds to load and uses available resources. This information can be used to calculate basic sizing and performance for specific applied scenarios. Results in your environment may vary. Attachmate recommends that you conduct performance testing with your particular combination of model(s), host(s), host application(s), network, server hardware, and server configuration to optimize your environment and meet your quality of service (QoS) requirements.

Runtime Performance and Requirements

This section describes session limits, memory usage, multi-processor/multi-core performance, and other performance variables.

Concurrent Sessions

When determining session limits for specific scenarios, consider the following factors:

• Peak concurrent client users ("active" sessions), or "high water mark": Although session server configuration supports up to 5000 concurrent sessions, the recommended maximum limit is 1000 concurrent active sessions per session server.

• Host sessions started simultaneously by clients: The recommended limit is 100 host sessions connecting in unison. This limit applies to client applications that do not use session pools (“connect to model”) or use session pools configured with minimal pre-loaded session counts.
• Client connections initiated simultaneously: When client applications are connecting to session pools with sufficient idle host sessions, the recommended limit is 250 client connections activated in unison. Session pools with pre-loaded host sessions provide significant performance improvement by reducing overhead when client applications connect.
• Host sessions started simultaneously by session pool initialization: If you have a large number of host sessions that pre-load concurrently, the host may be impacted when the session server service starts, depending on host hardware and capabilities. To avoid this impact, you can use multiple session pools with scripted staggered starts, or configure the session pool to create pooled sessions serially.
• Idle sessions: "Inactive" or "idle" sessions are host sessions that have already been started in a session pool, but are not currently being used by a client user. Since idle sessions have a low impact on CPU usage and network bandwidth, there is no specific recommended limit, but Attachmate recommends conducting on-site tests if there is a large number of inactive sessions.
• Multi-server scalability: Higher concurrent session requirements can be met with multiple session servers, thus distributing session load across multiple separate systems. For more information on load balancing, see Technical Notes 10052 and 10059.

Memory

The session server is highly efficient in memory usage, but does have specific needs related to model size and concurrent session count:

Note the following:

• For memory calculation purposes, “concurrent sessions” includes the peak total of all active, pre-loaded/idle, and suspended sessions.
• With more entities in a model, more memory is consumed per session. Although there can be wide variations in the complexities of entities (operations, patterns, recordsets, and event handlers), these attributes do not have a large impact on the memory consumption per entity. A model with 100 entities uses roughly twice the memory compared to a model with 10 entities. Example: With 200 concurrent sessions, a 10-entity model uses less than 85 MB of memory, and a 100-entity model uses 161 MB.
• As active sessions navigate more host screens, memory use increases. For examples, compare memory use for Search and Update procedures in the Test Results Data below.
• System memory beyond the above requirements does not increase server performance.

Processors

Multi-processor systems can improve session server performance. The session server takes advantage of multiple CPUs (symmetric multi-processing, or SMP) when available. A CPU is defined as a processor core, so a dual-core CPU is treated as two processors by the session server, and a quad-core CPU is treated as four processors.

Session server performance and load capability improves with each additional processor, but there is a diminishing marginal increase as the processor count is increased. The largest marginal increase in capability is realized with the second processor. Further performance gains are obtained with additional CPUs, but a diminished improvement is realized per additional processor.

Note the following:

• For best performance of Session Server on Windows, configure the number of Host Session Threads equal to the number of CPU cores, but not less than 2.
• VMware or other virtual environments may limit the number of CPU cores that are supported. Consult your virtual environment documentation.

Other Performance Variables

Note the following:

• Model size: Use of large or small models has little measurable effect on performance.
• Security: Performance is affected by enabling encryption in the client-server and/or server-host communication. When encryption is enabled, performance may be limited by client and/or host hardware capabilities due to encryption/decryption processing demands. (For more information on security, see Technical Note 10079.)
• Diagnostics: Enabling certain diagnostic tools (logging all messages) adds significant overhead, especially when log files are written to a journaling filesystem on Linux/UNIX platforms. (In a normal production environment, it is recommended to log and record errors only. For more information on configuring logging and model debug messages, see Technical Notes 40032 and 10066 respectively.)
• Event handlers: Model event handlers can impact performance, depending on the size, complexity, and number of event handlers. See also Event Handler Best Practices at http://docs.attachmate.com/verastream/vhi/6.6/doc/help/designtool/event_handler_design.html. The event handler script engine performs about 20% better on Linux compared to Windows.

Relative Performance Results

The following information summarizes how different VHI usage scenarios affect the time for the client to connect to the session server, and for the server to navigate each host application screen. For more information on the scenarios and time calculations, refer to the Test Details.

In the graphs below, shorter bars represent faster performance.

Figure 1. Connect time is fastest with session pools. Security adds connection overhead.
Figure 2. Enabling logging of all server messages slows runtime performance.

------------------------------------------------------------------------------------------------------------------------------

Test Details

If you are interested in how Attachmate testing labs measured performance, the following information describes the testing environment, methodologies, and results data.

Testing Environment

Tests were performed with the client, server, and host on separate systems on a 100 Mbps network.

Figure 3. Test systems

Server Hardware

Server Configuration

*For tests using the session pool (all tests except R1 and S1), the initial host sessions are pre-loaded, including completion of successful navigation to the home entity, before the test is initiated.

Models

Tests were performed with the following VHI models.

Client Application

The test client is a multi-threaded application that establishes multiple concurrent connections to the session server using the VHI Java Connector. The client requests execution of a Search procedure (resulting in model traversal of 28 screens) or an Update procedure (4 screens). Each client thread executes the procedure 10 times. For example, if the test is run with 100 clients, a total of 1000 transactions are executed. The client thread disconnects and re-connects between each transaction request, thus each transaction is handled with a separate client connection.

Host (Trace Player)

The host is emulated by Trace Player, an Attachmate utility. This utility is not provided with the product. For more information about Trace Player, contact Technical Support at http://support.attachmate.com/contact/.

Trace Player 3.20 was used with the following parameters:

Test Results Data

The tables below include the following measurements:

• # of Clients: This value represents the number of client threads, and peak number of concurrent client/host sessions (connecting in unison).
• # of Transactions: This value represents the total number of client connections, and total number of table procedure transaction requests.
• Time (sec): Total time (in seconds) to complete the number of procedure transactions, as measured from the client end.
• % Failed: Percentage of failed transactions. Failed connections (client calls resulting in errors) occur as a session server approaches one or more of its limits. Tests that scale aggressively enough will show a trend of increasing failed connections.
• Transactions / sec: Number of transactions executed per second (calculated run rate).
• Screens / sec: Number of entities traversed (screens navigated) per second (calculated run rate).
• Network Usage: Percent of network bandwidth used on the session server system, as reported by Windows Task Manager (Networking tab).
• CPU Usage: Sustained percent of available combined CPU processing power used on the session server system, as reported by Windows Task Manager (Performance tab).
• Memory (MB): Peak amount of memory used during the test by the VHI Session Server process (sesssrvr.exe) as reported in Windows Task Manager (Processes tab), converted and rounded to the nearest megabyte.

Test R1a: Connect to Model, Large Procedure

This test measures server performance of the Search procedure without any session pool, thus the concurrent client connections and host sessions are both started in unison.

Figure 4. Maximum performance at about 1,250 screens per second

# of Clients	1	5	10	20	30	50	75	100	125
# of Transactions	10	50	100	200	300	500	750	1000	1250
Time (sec)	1.11	1.81	2.92	5.28	7.77	13.33	19.61	26.47
% Failed	0	0	0	0	0	0	0	0	2.32%
Transactions / sec	9.01	27.62	34.25	37.88	38.61	37.51	38.25	37.78
Screens / sec	297	912	1,130	1,250	1,274	1,238	1,262	1,247
Network Usage	7%	18%	25%	25%	27%	27%	25%	26%	27%
CPU Usage	6%	25%	30%	33%	34%	32%	31%	32%	31%
Memory (MB)	26	27	27	29	30	34	40	48	54

Test R1b: Connect to Model, Small Procedure

This test measures server performance of the Update procedure without any session pool.

Figure 5. Maximum performance at about 400 screens per second

# of Clients	1	5	10	20	30	50	75	100
# of Transactions	10	50	100	200	300	500	750	1000
Time (sec)	0.53	1.26	2.36	4.42	6.64	11.27	16.92
% Failed								1.10%
Transactions / sec	18.87	39.68	42.37	45.25	45.18	44.37	44.33
Screens / sec	170	357	381	407	407	399	399
Network Usage	2%	3%	8%	10%	11%	11%	11%	10%
CPU Usage	5%	6%	13%	16%	17%	15%	17%	18%
Memory (MB)	15	15	17	19	23	29	37	45

Calculating Results for Connect to Model

Each Search transaction has 33 screen traversals, and about 1,250 screen traversals per second. Each Update transaction has 9 screen traversals, and about 400 screen traversals per second. With these values, we can calculate the time per screen traversal and connection time per transaction.

Test R2a: Connect to Session Pool, Large Procedure

This test measures server performance of the Search procedure with a session pool. For all tests using session pools, the server is configured for 250 initial sessions in the session pool, and 5000 sessions maximum.

Figure 6. Maximum performance at about 3,000 screens per second

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225	250
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250	2500
Time (sec)	1.05	1.2	1.6	2.6	3.63	5.09	7.55	10.3	11.69	13.69	17.01	19.95	20.63	23.78
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	0	0
Transactions / sec	9.52	41.67	62.50	76.92	82.64	98.23	99.34	97.09	106.93	109.57	102.88	100.25	109.06	105.13
Screens / sec	267	1167	1750	2154	2314	2750	2781	2718	2994	3068	2881	2807	3054	2944
Network Usage	3%	16%	35%	50%	55%	65%	68%	70%	75%	75%	78%	76%	79%	77%
CPU Usage	6%	6%	11%	43%	53%	64%	71%	86%	95%	95%	96%	99%	99%	99%
Memory (MB)	98	98	99	101	103	103	110	115	135	121	139	163	171	178

Test R2b: Connect to Session Pool, Small Procedure

This test measures server performance of the Update procedure with a session pool.

Figure 7. Maximum performance at about 625 to 650 screens per second

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225	250
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250	2500
Time (sec)	0.36	0.50	0.83	1.57	2.38	3.78	5.39	6.84	8.32	9.76	11.11	12.88	14.00	15.22
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	0	0
Transactions / sec	27.78	100.00	120.48	119.76	126.05	132.28	139.15	146.20	150.24	153.69	157.52	155.28	160.71	164.26
Screens / sec	111	400	482	479	504	529	557	585	601	615	630	621	643	657
Network Usage	2%	7%	10%	17%	21%	22%	24%	23%	25%	29%	28%	29%	29%	30%
CPU Usage	2%	9%	11%	14%	24%	28%	32%	33%	38%	45%	48%	49%	46%	47%
Memory (MB)	97	97	97	98	98	98	100	100	103	105	105	107	105	105

Calculating Results for Connect to Session Pool

Each Search transaction has 28 screen traversals, and about 3,000 screen traversals per second. Each Update transaction has 4 screen traversals, and about 625 screen traversals per second. With these values, we can calculate the time per screen traversal and connection time per transaction.

Test R3a: Security Enabled, Large Procedure

This test measures server performance of the Search procedure with a session pool and security enabled in the server configuration. Due to overhead for authentication and encryption in client-server communication, performance is reduced compared to test R2a.

Figure 8. Maximum performance at about 310 screens per second

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250
Time (sec)	3.06	5.67	10.55	19.64	28.66	48.45	69.47	88.72	112.59	133.64	151.78	179.5
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	high
Transactions / sec	3.27	8.82	9.48	10.18	10.47	10.32	10.80	11.27	11.10	11.22	11.53	11.14
Screens / sec	92	247	265	285	293	289	302	316	311	314	323	312
Network Usage	2%	5%	7%	11%	14%	16%	17%	17%	20%	22%	16%	18%	20%
CPU Usage	3%	7%	9%	15%	22%	33%	35%	42%	38%	40%	42%	37%	39%
Memory (MB)	97	98	99	100	104	106	117	122	121	137	146	158	171

Test R3b: Security Enabled, Small Procedure

This test measures server performance of the Update procedure with a session pool and security enabled in the server configuration. Due to overhead for authentication and encryption in client-server communication, performance is reduced compared to test R2b.

Figure 9. Maximum performance at about 46 screens per second

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225	250
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250	2500
Time (sec)	2.50	5.47	9.94	18.80	28.10	45.37	66.89	88.92	107.46	130.05	149.09	171.75	192.43
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	0	3.88%
Transactions / sec	4.00	9.14	10.06	10.64	10.68	11.02	11.21	11.25	11.63	11.53	11.74	11.64	11.69
Screens / sec	16	37	40	43	43	44	45	45	47	46	47	47	47
Network Usage	1%	2%	2%	3%	4%	8%	9%	11%	10%	12%	11%	12%	12%	13%
CPU Usage	2%	3%	5%	6%	7%	9%	8%	15%	14%	17%	16%	18%	16%	16%
Memory (MB)	97	98	98	99	99	100	103	106	109	109	110	114	120	123

Calculating Results with Security Enabled

Each Search transaction is about 310 screen traversals per second, and each Update transaction is about 46 screen traversals per second. With these values, the time per screen traversal and connection time per transaction can be calculated:

Test R4a: All Logging and Recording Enabled, Large Procedure

This test measures server performance of the Search procedure with a session pool, session server configured to Log All Messages, and model debug messages configured to record everything. All files are written to the same local server drive. Due to the increased disk write activity associated with logging all messages, performance is reduced compared to test R2a.

Figure 10. Maximum performance at about 385 screens per second

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000
Time (sec)	1.16	3.41	8.11	15.14	21.17	35.50	55.01	73.67	89.30	108.48	127.07	146.97
% Failed	0	0	0	0	0	0	0	0	0	0	0	0
Transactions / sec	8.62	14.66	12.33	13.21	14.17	14.08	13.63	13.57	14.00	13.83	13.77	13.61
Screens / sec	241	411	345	370	397	394	382	380	392	387	386	381
Network Usage	3%	9%	8%	8%	8%	8%	8%	9%	9%	9%	8%	9%
CPU Usage	3%	4%	4%	3%	4%	3%	4%	4%	4%	4%	4%	3%
Memory (MB)	97	99	100	103	106	113	123	132	145	154	164	180

Test R4b: All Logging and Recording Enabled, Small Procedure

This test is the same as test R4a, except with the Update procedure. Due to the increased disk write activity associated with logging all messages, performance is reduced compared to test R2b.

Figure 11. At high concurrency, performance is about 110 screens per second

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250
Time (sec)	0.44	0.72	2.02	4.37	9.28	18.23	25.20	37.11	45.64	54.25	62.41	73.43	81.83
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	0
Transactions / sec	22.73	69.44	49.50	45.77	32.33	27.43	29.76	26.95	27.39	27.65	28.04	27.24	27.50
Screens / sec	91	278	198	183	129	110	119	108	110	111	112	109	110
Network Usage	1%	2%	10%	12%	8%	8%	7%	7%	7%	7%	7%	7%	7%
CPU Usage	2%	11%	15%	13%	11%	8%	6%	5%	5%	4%	4%	4%	4%
Memory (MB)	98	98	98	99	101	102	103	106	107	112	112	128	135

Calculating Results with Logging and Recording

Each Search transaction is about 385 screen traversals per second, and each Update transaction is about 110 screen traversals per second. With these values, the time per screen traversal and connection time per transaction can be calculated:

Test S1a: Connect to Model, Event Handlers, Large Procedure

This test measures server performance of the Search procedure without any session pool, and with 200 event handlers. Due to the event handler overhead, performance is reduced compared to test R1a.

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000
Time (sec)	1.78	2.92	4.45	8.05	10.83	17.21	24.77	31.72	40.73	48.51	57.28
% Failed	0	0	0	0	0	0	0	0	0	0	0	3.10%
Transactions / sec	5.62	17.12	22.47	24.84	27.70	29.05	30.28	31.53	30.69	30.92	30.55
Screens / sec	185	565	742	820	914	959	999	1040	1013	1020	1008
Network Usage	2%	12%	17%	18%	20%	20%	20%	21%	21%	22%	23%	23%
CPU Usage	7%	20%	46%	57%	69%	79%	83%	85%	84%	85%	85%	84%
Memory (MB)	15	16	18	21	25	32	40	48	55	63	73	80

Test S1b: Connect to Model, Event Handlers, Small Procedure

This test measures server performance of the Update procedure without any session pool, and with 40 event handlers. Due to the event handler overhead, performance is reduced compared to test R1b.

# of Clients	1	5	10	20	30	50	75	100	125
# of Transactions	10	50	100	200	300	500	750	1000	1250
Time (sec)	0.89	1.69	2.77	4.98	6.86	11.97	17.92	23.95
% Failed	0	0	0	0	0	0	0	0	0.40%
Transactions / sec	11.24	29.59	36.10	40.16	43.73	41.77	41.85	41.75
Screens / sec	101	266	325	361	394	376	377	376
Network Usage	2%	7%	9%	10%	11%	12%	12%	12%	12%
CPU Usage	5%	17%	43%	47%	48%	51%	49%	50%	48%
Memory (MB)	15	16	18	21	25	30	39	47	54

Test S2a: Connect to Session Pool, Event Handlers, Large Procedure

This test measures server performance of the Search procedure with a session pool and 200 event handlers. Due to the event handler overhead, performance is reduced compared to test R2a. However, using the session pool improves performance compared to test S1a.

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225	250
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250	2500
Time (sec)	1.69	2.17	3.01	5.63	8.21	13.18	19.47	26.22	32.92	39.3	45.41	53.41	58.94
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	0	5.64%
Transactions / sec	5.92	23.04	33.22	35.52	36.54	37.94	38.52	38.14	37.97	38.17	38.54	37.45	38.17
Screens / sec	166	645	930	995	1023	1062	1079	1068	1063	1069	1079	1048	1069
Network Usage	2%	13%	22%	23%	25%	25%	25%	26%	26%	26%	25%	27%	26%	27%
CPU Usage	6%	32%	86%	85%	87%	88%	90%	90%	90%	91%	89%	90%	90%	90%
Memory (MB)	99	100	101	105	106	112	116	126	131	152	156	174	173	175

Test S2b: Connect to Session Pool, Event Handlers, Small Procedure

This test measures server performance of the Update procedure with a session pool and 40 event handlers. Due to the event handler overhead, performance is reduced compared to test R2a. However, using the session pool improves performance compared to test S2a.

# of Clients	1	5	10	20	30	50	75	100	125	150	175	200	225	250
# of Transactions	10	50	100	200	300	500	750	1000	1250	1500	1750	2000	2250	2500
Time (sec)	0.77	1.02	1.21	2.01	3.31	4.94	7.06	9.47	12.08	14.34	16.34	19.12	23.61
% Failed	0	0	0	0	0	0	0	0	0	0	0	0	0	0.40%
Transactions / sec	12.99	49.02	82.64	99.50	90.63	101.21	106.23	105.60	103.48	104.60	107.10	104.60	95.30
Screens / sec	52	196	331	398	363	405	425	422	414	418	428	418	381
Network Usage	3%	8%	13%	13%	13%	14%	15%	16%	16%	17%	17%	17%	18%	20%
CPU Usage	5%	30	54	62	80	87	90	90	90	90	89	90	89	89
Memory (MB)	98	98	100	100	100	102	104	106	107	111	114	118	123	129