Contents | Previous | Next

SSL Multiple Server Support

Abstract

With SSL Multiple Server Support the TCP/IP stack can now use multiple SSL servers, thus removing the SSL server as a limiting factor and improving the scalability of SSL.

In the 2000 Telnet connection rampup environment, SSL Multiple Server Support consumed the same amount of CPU per new connection as the number of existing connections increased to 2000. In the previous level of SSL, the CMS-based SSL server, the CPU continued to increase as the number of existing connections increased to 2000. Compared to Linux-based SSL, SSL Multiple Server Support consumed more CPU with a lower number of existing Telnet connections, but as the number of existing connections reached 2000, SSL Multiple Server Support consumed less CPU than the Linux-based SSL server.

In the Telnet data transfer workload, SSL Multiple Server Support showed a 34.2% CPU improvement. In the FTP large-file data transfer workload, SSL Multiple Server Support showed a 32.5% CPU degradation. In the SMTP workload, SSL scalability was improved with SSL Multiple Server Support. Because the SMTP workload did not scale up with CMS-based SSL version, there was no base measurement.

Introduction

With SSL Multiple Server Support the restriction of having one SSL server per TCP/IP stack is removed. With the new enhanced SSL the maximum number of SSL servers is defined by the administrator. By default there are five SSL servers with each server supporting up to 600 connections for a total of 3000 connections. TCPIP establishes connections using a "waterfall" method. That is, when one SSL server has the maximum number of connections in use, TCPIP will start using the next SSL server.

This report evaluates the performance benefits when the TCP/IP stack has access to multiple SSL servers. The evaluation includes the Telnet, FTP, and SMTP interfaces. Performance evaluation will be further broken down into connect-time performance and data-transfer performance. Results will be compared back to the CMS-based SSL server and the Linux-based SSL server.

Background

Following the introduction of the CMS-based SSL server with z/VM 540, and its functional enablement via the PTF for APAR PK65850, IBM recognized and acknowledged several performance and scalability limitations with this implementation. These are discussed in the intial CMS-Based SSL Server z/VM Performance Report.

With z/VM 5.4.0 or z/VM 6.1.0, APARs PK97437, PK97438, and PK75662 are required to enable one TCP/IP stack to connect to a single-instance SSL server or a server "pool", for which multiple SSL servers are employed. This will improve the scalability with respect to the number of concurrent secure connections allowed per TCP/IP stack. It also increases the connection "back-up" capability through the use of multiple SSL pool servers with a given TCP/IP stack server. The failure of a given SSL pool server will not disrupt future connectivity, nor will it cause the associated TCP/IP stack server (or, a dependent application protocol server, such as an FTP server) to shut down.

The IBM default server pool configuration employs five SSL servers (SSL00001, SSL00002,...SSL00005), where each server is configured to support a maximum of 600 connections (via the MAXPERSSLSERVER operand of the TCP/IP server SSLLIMITS statement). As it will be demonstrated below, this MaxPerSSLServer value can affect the performance of an individual SSL server. Thus, this value can be used as a performance tuning knob. For more information on maximum sessions and maximum sessions per individual SSL servers, see TCP/IP for z/VM SSL Server Performance and Scalability Enhancements TCP/IP Server Configuration Updates.

For more information on how to install and configure a single-instance SSL server or an SSL server "pool" and a complete list of required APARs, see TCP/IP for z/VM SSL Server Performance and Scalability Enhancements Planning and Installation Information.

Method

Four different workloads were used to evaluate the benefits experienced when a "pool" of SSL servers were applied in several different base case configurations.

The first base-case environment studied the Telnet-connect environment in which 2000 remote Linux telnet connections were established. A delay of one second was used in between each connection. Once established, the connection remained idle throughout the measurement.

The second base-case environment studied a Telnet data-transfer environment in which 200 existing remote Linux Telnet connections issued 'QUERY DASD' within an exec in parallel for 180 seconds. A delay of one second was used in between queries. This resulted in the data being outbound from the z/VM system.

The third base-case environment studied an SMTP data-transfer environment in which 40 remote CMS users transferred a small file in parallel for 60 seconds. A delay of one second was used in between file sends.

The last base-case environment studied an FTP data-transfer environment in which 1 CMS user transferred a large file (32M).

The following table contains the configuration parameters for the four base-case environments. For all measurements, IBM used a System z9 and its CP Assist for Cryptographic Function (CPACF) facility. It should be noted that the system was configured to avoid any system constraints.

SSL workload parameters for various base-case environments

Results and Discussion

Telnet Connection

Figure 1 shows the SSL CPU time to establish a new connection versus existing connections.

Figure 1. SSL CPU Time To Establish a New Connection versus Existing Connections: Processor z9, CPACF Support, Cipher: 3DES_168_SHA (high)

The CMS-based SSL measurement showed that as the number of concurrent connections increased, the CPU time to establish a new connection increased. This increase was due to the CMS thread-model implemented in CMS-based SSL server. For more details on CMS-based SSL, see the CMS-based SSL Performance Report.

The SSL Multiple Server Support measurement showed the CPU time remained constant as the number of concurrent connections increased. This was due to the distribution of connections among the 10 SSL servers therefore the CMS-Select algorithm was not being over utilized.

If the number of connections per server had been configured higher than 200 connections/server, the CPU required to create a new connection would have increased per connection. Therefore, this value can affect the performance of the SSL server and thus should be configured/set appropriately for a given workload. For a general guideline for capacity planning based on IBM's Performance analysis, see Server Configuration Considerations.

With a smaller number of connections, the Linux-SSL server consumed less CPU than SSL Multiple Server Support. The gap decreased as the number of existing Telnet connections reached 2000. With Linux-SSL, the limiting factor was the SSL server itself. Using SSL Multiple Server Support, the SSL server was no longer the limiting factor.

Telnet, FTP, SMTP Data Transfer Environments

Table 1. SSL and TCPIP CPU utilizations for various workload environments

Table 1 shows the CPU/tx cost for the Telnet, FTP, and SMTP workloads.

For the Telnet environment, the SSL server total CPU/tx decreased by 34.2% in the SSL Multiple Server environment. Ninety-nine percent of the savings came from virtual time or the SSL server.

In the FTP environment, total CPU/tx increased by 32.5% in the SSL Multiple Server Support environment. IBM development is aware of this problem.

In the SMTP environment, scalability was improved in the SSL Multiple Server Support environment. Because the SMTP workload did not scale up in the CMS-based SSL version, there was no base measurement.

Summary and Conclusions

Overall, SSL Multiple Server Support improved connection scalability and improved CPU time in most environments. Compared to the CMS-based SSL, the CPU time required to create a new connection decreased with existing connections. This value can vary depending on how many connections are configured per SSL server. As the number of connections per SSL server configured increases, the CPU cost to establish a new connection increases.

The Telnet data transfer environment showed a CPU/tx improvement with SSL Multiple Server Support. The FTP environment showed a CPU/tx degradation while the response time remained the same with the SSL Multiple Server Support. The SMTP environment did not scale in the CMS-based SSL environment, therefore the SSL Multiple Server Support environment could not be compared to a base environment.

Contents | Previous | Next