SPEC logo

SPECweb99_SSL Design and Implementation Overview

SPECweb99_SSL is a software benchmark product designed to test secure web server performance using HTTP over SSL (HTTPS).  The benchmark is built upon the SPECweb99 test harness and uses the same workload and file set (see:  http://www.spec.org/osg/web99/).

In SPECweb99_SSL, the HTTP GETs and POSTs of SPECweb99 are replaced with the corresponding GETs and POSTs using HTTPS.  This paper documents the changes made to the SPECweb99 design and implementation to support SSL. To review the SPECweb99 design see: http://www.spec.org/osg/web99/docs/whitepaper.html.

Server Changes

The Secure web server software used on the server being tested with SPECweb99_SSL must support HTTP over SSLv3 or TLS (http://www.ietf.org/rfc/rfc2818.txt). Of the various ciphers supported in SSLv3, only cipher SSL_RSA_WITH_RC4_128_SHA is currently required for SPECweb99_SSL.  It was selected as one of the most commonly used SSLv3 ciphers and allows results to be directly compared to each other. SSL_RSA_WITH_RC4_128_SHA consists of:

Client  Changes

The client or load generator has been updated to handle HTTPS by using the OpenSSL library (www.openssl.org).  The clients will still generate the same mix of GETs and POSTs in SPECweb99, but SSL will be used to encrypt these operations. It is expected that systems used as SPECweb99_SSL load drivers will only generate a fraction of the load that the same system would be capable of under SPECweb99.  The decrease is due to the additional work required by the client to encrypt the request and then decrypt the response.  A SPECweb99_SSL client might only generate 30-40% of the number of simultaneous connections when compared with SPECweb99.

Client Code Modifications
  The changes to SPECweb99 for SPECweb99_SSL include the following updates to the client load driver modules:
Supporting Tools and Libraries

The support tools such as specperl have been replaced and supplemented.  A major new element is the inclusion of the OpenSSL library code.  This tool kit has been successfully built on various UNIX, LINUX, and Windows (WIN32) systems.  The tool kit provided includes the following open source tools, perl modules, and libraries:

User Interface Changes

Only minor changes were required to the user interface to replace "http" references with "https" within the following rc file parameters:  URL_ROOT, DYNAMIC_ROOT, DYN_GET_SCRIPT, DYN_CAD_SCRIPT,  DYN_POST_SCRIPT, DYN_CMD_SCRIPT, and DYN_CGI_SCRIPT.

Example: URL_ROOT=http://server1 => URL_ROOT=https://server1.

The Benchmark/Metric name on the reporting page was updated to SPECweb99_SSL and several labels updated to reference HTTPS.

 
Integrating SSL into the SPECweb99 Workload

In SPECweb99_SSL, the client systems will generate the same mix of static and dynamic GETs and POSTs as SPECweb99, however now the clients will negotiate SSL connections with the server and all requests and responses will be encrypted.  Each connection will establish an SSL session and the session may be resumed for several sequential HTTP operations.

Since many secure web servers support SSL session resumption, this feature has been included in SPECweb99_SSL.  The SPECweb99_SSL client is written to attempt session resumption for sequences of requests before forcing a new SSL session to be negotiated. Since SPECweb99 was written to issue a mix of persistent and non-persistent requests, SPECweb99_SSL takes advantage of the existing design and uses the last response to a sequence of persistent or Keep-Alive requests to indicate that the next request should discontinue session resumption and request a new session id from the server.

It should be noted that the server may also attempt to renegotiate an SSL session even if the client has indicated that the session can be resumed.  The actual number of session_id's negotiated by the server may depend on the server's configuration and implementation.

Given the current workload and assuming that the server creates a new session only when the client indicates, then there would be an average of roughly 4 session resumptions for each new session.  The number of session resumptions would vary between 1 and 12 with occasional higher peaks.