SPEC virt_sc ® 2013 User's Guide

Version 1.11 - July 8, 2019



1.0 Requirements

This guide assumes that you are using the SPEC virt_sc ® 2013 version and that you have familiarity with virtualization concepts and implementations. You require experience with the installation, configuration, management, and tuning of your selected hypervisor platform. You must know how to use your virtualization platform to create, administer, and modify virtual machines and allocate system resources including: The following resource allocations (number of vCPUs, amount of memory, VM disk sizes) are guidelines that submitters have used successfully in publications. The OS and workload applications used in your VMs may require more (or less) allocation than the below recommendations.

1.1 Client minimum requirements

A client machine should be able to drive a complete tile's workload if it has the following minimum characteristics:
You can use more than one physical client, virtual client, or a combination to drive a tile.

Note: Due to network latency, we recommend that you create a separate, dedicated webserver client. Instructions for this are in Appendix B of the SPEC virt_sc Client Harness User's Guide.

1.2 VM minimum requirements

When creating VMs, use your preferred virtualization software to create a virtual machine that has enough virtual CPUs, virtual memory, virtualized network interfaces, and virtual disk space to run your operating system and workload software successfully.

Each tile uses at least 110 GB storage per tile + 32 GB per database server for every four tiles. When configuring LUNs, consider using several physical disks in a RAID 5 or RAID 10 configuration. You do not need to co-locate a tile's VMs on one LUN; VMs from different tiles can be located on a single LUN.

1.2.1 Storage minimum requirements

Each workload uses at least the following storage:

Workload
Virtual disk (GB)
appserver 12
dbserver 32 (20 GB datastore)
infraserver 44 (32 GB datastore)
webserver 12
mailserver 26 (16 GB datastore)
batchserver 16

1.2.2 VM creation and network configuration

Once your virtual machine is created, install your preferred operating system in the newly created virtual machine. Configure a network interface to be connected to an external network over which the clients and VMs communicate. We recommend configuring another virtual network interface on the appserver VMs and webserver VMs to be connected to an internal network that the VM can use to communicate with the dbserver and infraserver VMs respectively. Since the communications are intra-SUT, this internal network does not have to be associated with a physical network port. For example, on the VM:

cat /etc/sysconfig/network-scripts/ifcfg-eth0
#public IP to/from clients
NAME=eth0
ONBOOT=yes
BOOTPROTO=static
NETMASK=255.255.0.0
IPADDR=172.168.122.64
cat /etc/sysconfig/network-scripts/ifcfg-eth1
#private intra-SUT IP communicates over Virtual NIC to other VMs only
NAME=eth1
ONBOOT=yes
BOOTPROTO=static
NETMASK=255.255.255.0
IPADDR=10.0.0.64

1.2.3 VM software requirements

All software used must be currently supported per the SPEC virt_sc 2013 Run and Reporting Rules.
On all VMs except for the application server and batch server, install your preferred Java 6 or greater Compatible JRE software. On the application server and batch server VMs, install Java 6 or greater Compatible JDK software. A JRE is needed by the SPECpoll code that runs on all the VMs. SPECjAppServer2004 and SPEC CPU2006 require a JDK. The Java JRE and JDK environments that are distributed with many Linux distributions may not be sufficient.

To ensure you are using the correct version, issue:

java -version

2.0 Setting up the test environment

The SPEC virt_sc benchmark consists of four workloads:
While these four workloads are based on standalone SPEC benchmarks, the actual workloads used in SPEC virt_sc are highly modified.  Therefore, the setup of these workloads in the SPEC virt_sc test environment differ somewhat from setting up the workloads in their standalone form. 

Note: If you have a mix of Windows and Linux/Unix operating systems in your SPEC virti_sc configuration, it is recommended that you run a program such as dos2unix on all files modified under Windows and then copied to Linux/Unix.  This prevents file formatting errors which are difficult to track down.

2.1 SPECpoll setup on all VMs

The pollme.jar listener code of SPECpoll needs to be running on all VMs during the test and requires Java 6 or greater Compatible JRE software. The Java runtime environment that comes with many Linux distributions may not be sufficient.

Configure the operating system running on all workload VMs to start the listener automatically on boot (for example, in /etc/rc.local), or have the client start the listener as a part of the test run. The command to start on this VM looks something like this:

java -jar /opt/SPECpoll/pollme.jar -p 8001

For more detailed information on SPECpoll and pollme.jar, see the SPEC virt_sc Client Harness User's Guide.

2.2 Infraserver VM workload setup

The infraserver VM contains files that need to be accessed by the webserver VM. The infraserver VM also acts as the back end simulator (BeSim) for the SPECweb2005 workload.

These are the steps for setting up the infraserver VM:
  1. Copy the SPECweb2005 directory from the harness kit onto a directory on the infraserver virtual machine.  (/opt for example)
  2. Setup a remote filesystem.
  3. Create a filesystem with 32 GB of space.
  4. Configure the filesystem to be accessible by the webserver VM (for example, exporting the filesystem using NFS).
  5. To set up the BeSim functionality:
    1. Configure the system with Web server software installed on port 81 or another port (avoid port 80 to avoid confusion with the primary web server).
    2. Build your BeSim code as instructed in Appendix A. Select a BeSim implementation compatible with your Web server software (FastCGI*, ISAPI, or NSAPI), edit the appropriate MakeIncl.* file to reflect your compile and linker options, and select one or more Defines. Then you can build the BeSim code for your selected API. (If using FastCGI, copy the FastCGI executable from the Redistributed Open Source code directory into the BeSim directory.)
    3. Install this code to your BeSim Web server.
    4. Start your BeSim Web server.
    5. Use the test_besim_support scripts (included in the "besim" subdirectory of the installation) to test whether you're getting valid BeSim responses. Both Perl scripts and Linux bash scripts are provided. The Perl scripts require a Perl interpreter as well as the following Perl modules: URI, HTML-Tagset, HTML-Parser, and libwww-perl. The bash scripts require cURL to be in the path.
Note: For more FastCGI instructions (particularly for the Apache HTTP Server), see Appendix B.

If you have additional questions about setting up your BeSim server you may want to refer to the SPECweb2005 User's Guide. Note that the SPEC virt_sc harness only uses a modified version of the Support workload from SPECweb2005, so the Ecommerce and Banking workloads do not need to be setup.

2.3 Webserver VM workload setup

The webserver VM runs web server software that hosts a SPECweb2005-based Support workload using Secure Sockets Layer (SSL) or the newer Transport Layer Security (TLS).

SSLv3 and the commonly-used SSL_RSA_WITH_RC4_128_MD5 cipher are enabled by default. If you choose SSL, the configuration files do not require editing. If your application stack requires TLS, see Appendix C.

Make sure you perform the steps for the infraserver VM for your tile in the previous section and power it on before setting up webserver. The webserver VM must have the support/downloads directory remotely accessible from the infraserver VM. This remote access point also needs to be present during web workload file generation.
  1. Copy the SPECweb2005 directory from the harness kit onto a directory on the web server virtual machine.  (/opt assumed for the purposes of the examples)
  2. Set localization on the system to US.
  3. Install and configure your favorite web server software with PHP and SSL or TLS support (see Appendix C for TLS). Note, the web server software should be configured for HTTPS (port 443) and HTTP (port 80), which is used for initialization.
  4. Set your current working directory to the wafgen directory:

    cd /opt/SPECweb2005/wafgen
  5. Make the document root support/downloads directory a fileserver mount from the infraserver VM. (You may want to use a VM internal network for this mount if available.)
    1. Go to the SPECweb2005/wafgen directory and edit the support wafgen files to set the TILEINDEX value for the tile you are creating.
    2. Edit /opt/SPECweb2005/wafgen/unix/support_downloads_props.rc and set the parameter TILEINDEX equal to the tile number minus 1 (for example, set TILEINDEX=1 for tile 2).
    3. Edit /opt/SPECweb2005/wafgen/unix/support_image_props.rc and set the parameter TILEINDEX equal to the tile number minus 1 (for example, set TILEINDEX=1 for tile 2)
    4. Build the image files:

      ./Wafgen unix/support_image_props.rc

    5. Build the support files:
./Wafgen unix/support_downloads_props.rc

Note that this command could take over an hour to run.
6.  Set up PHP.
  1. Copy the contents of the /opt/SPECweb2005/Scripts/PHP/* directory to your document root:

    cp -ar /opt/SPECweb2005/Scripts/PHP/* /var/www/html/

  2. Verify the "support" and "Smarty-2.6.26" subdirectories are under the document root. Ensure the web server has read and write access to these directories and subdirectories. From the document root:
chmod -R a+rw support/ Smarty-2.6.26/

An alternative is to use chown to assign ownership to the Web server user/group.

The stock PHP distribution ships with two ini files: php.ini-dist and php.ini-recommended. While php.ini-recommended is optimized for performance and security, for initial troubleshooting, php.ini-dist may be a better choice. This configures PHP to display errors in the browser. If PHP comes with your OS distribution, you may only have one php.ini, in which case you should consider changing "display_errors" and "display_startup_errors" to "On".  You may also want to set "error_reporting = E_ALL" to display all errors and warnings.

Since the data created for the webserver VM workload is specific to a particular tile, the data files cannot be copied and used on the webserver VMs of different tiles. Each webserver must build its own image and support files.

If you have additional questions about setting up your web server, see the SPECweb2005 User's Guide. Note that the SPEC virti_sc harness only uses a modified version of the Support workload from SPECweb2005, so the Ecommerce and Banking workloads do not need to be setup.

2.4 Mailserver VM workload setup

  1. Copy the SPECimap directory from the harness kit onto a directory on the mailserver virtual machine.  (/opt assumed for the purposes of the examples)
  2. Install your preferred IMAP server software.
  3. Configure a storage location in your IMAP server that can hold 14 GB of data.
  4. Set up 500 users in your IMAP server software for the benchmark. See below.
  5. Load the user accounts with data using the SPEC virt_sc 2013 IMAP loader before you run the benchmark. The load may be initiated from either a client machine or from the mailserver VM itself.
    1. Modify the IMAP config file (/opt/SPECimap/IMAP_config.rc)  for the load. Replace the CLIENTS variable with the hostname of this mailserver VM followed by port 1200:

      CLIENTS = "mailserver1:1200"

      A high thread count (such as 100) is recommended to expedite the loading process in the next step. This can be set by changing the THREADS_PER_CLIENT line from 1 to a higher value; 100 has worked for some, but 20 may be a safer value.
    2. Use the run_load_gen and run_init .sh or .bat files to load the mailstore:

      cd /opt/SPECimap
      ./run_load_gen.sh       (in one virtual terminal or command shell)
      ./run_init.sh (in a second virtual terminal or command shell)

      Note: This step populates the IMAP server with messages and may take more than 20 minutes to complete.
Once the load is finished, you need to kill the specimapclient Java process that is left running.

Once a mailstore is created and loaded, it can be copied and used as the mailstore on other tiles. We recommend backing up the mailstore once it has had the workload run against it and use this "warmed up" version of the mailstore for the restores. This "warm up" period may need to be a few hours depending on your IMAP server.

2.4.1 Creating user accounts on the mailserver

You need to create 500 user accounts on your mailserver for the benchmark and they must be of the form <USERNAME_PREFIX><USER_ID>, for example test1 and test500. The USERNAME_PREFIX is defined in the configuration file SPECimap/IMAP_config.rc and defaults to test. This parameter can be changed if needed to create users in your IMAP server. Each user has a unique user ID which is a number whose lower and upper bounds are defined in the SPECimap/IMAP_config.rc configuration file.

Note:  Some IMAP server software may also require you to create corresponding operating system or domain user accounts.

2.5 Database server VM workload setup

The dbserver VM acts as the database backend for the SPECjAppServer2004 workload.  SPEC virt_sc 2013 has modified the workload to access across 25 times more database data than the usual SPECjAppServer2004 workload at a given injection rate.  This means that the average SPEC virt_sc 2013 driver injection rate of 1000 accesses a database sized for an injection rate of 500.

Note: The database server VM requires at least two vCPUs per tile.
  1. Copy the SPECjAppServer2004 from the harness kit onto a directory on the database server virtual machine.  (/opt assumed for the purposes of the examples)
  2. Install your preferred database software and configure. The configuration for your database server software needs to be tuned to handle the peak injection rate (IR) of 45.
  3. Configure a storage location in your database software that can hold 20 GB of data.
  4. Load your database for a SPECjAppServer2004 injection rate (IR) of 500. If desired, you can also run these steps to load the database from the client rather than from the dbserver VM.
  5. Modify the /opt/SPECjAppServer2004/config/run.properties file on the client so the variable txRate=500.
  6. Create the database schema using scripts specific to your database. You can find example schemas in the SPECjAppServer2004/schema directory. After the schema is created, execute:

    SPECjAppServer2004/bin/loaddb.sh 500

    Note: To load the database successfully, consider editing the loaddb.sh to increase Java heap minimum and maximum size in the Java command line.

  7. After the load finishes, ensure the value of txRate in /opt/SPECjAppServer2004/config/run.properties is at the runtime injection rate of txRate=100. Backup the database once it has been built.
The database backup can be copied and used on other tiles. A backup of the database is required because a database restore needs to be done before each benchmark run.

2.6 Application server VM workload setup

Make sure you have done the setup steps for the dbserver VM and that the dbserver VM for your tile is powered on before setting up the corresponding appserver VM. The appserver VM accesses the database contained on the dbserver VM.
  1. Copy the SPECjAppServer2004 directories from the harness kit onto a directory on the appserver server virtual machine.  (/opt assumed for the purposes of  the examples)
  2. Install your preferred J2EE application server software.  Note: For SPEC virt_sc 2013, the Supplier Emulator (emulator.ear) MUST reside on the appserver VM.
  3. Setting up a SPECjAppServer2004 environment is challenging. We strongly recommend using an application stack from a previously published SPECjAppServer2004 result. The SPECjAppServer2004 Full Disclosure Archive associated with a result contains useful files and information that would help set up application and database server software.
Refer to the SPECjAppServer2004 User Guide to setup your J2EE application server for the SPECjAppServer2004 workload.  The database portion of the SPECjAppServer test is set up on the dbserver VM.

The configuration for your J2EE application server needs to be tuned to handle a peak SPECjAppServer2004 injection rate (IR) of 200 (2,600 active web connections).

2.7 Batchserver VM workload setup

  1. Copy the SPECbatch directory from the harness kit onto a directory on the batch server virtual machine (/opt assumed for the purposes of the examples).
  2. Make sure your preferred Java 6 or greater Compatible JDK software is installed. The Java runtime environment that comes with many Linux distributions may not be sufficient.
  3. Unpack the cpu2006-virt.tgz workload archive into the /opt/SPECbatch directory. After the extraction, you should see a cpu2006-virt directory.
  4. From the cpu2006-virt directory, run install.sh (install.bat for Windows). Accept the default options.
  5. Build the 401.bzip2 "base" executable. See the SPEC CPU2006 documentation for details and minimum requirements for base optimizations.
  6. Customize your batch run script. The sample run script virt_sc2013_run.sh is included in the kit and provides guidance in what is needed for such a script.
  7. Configure the VM's operating system to start the SPECbatch listener automatically on boot (for example, in /etc/rc.local), or have the client start the listener as a part of the test run. The command to start on this VM looks something like this:

    java -jar /opt/SPECbatch /batch.jar -p 1901
Note: You need a compiler present and configured on the VM. There are several example configuration files for different OS/compiler platforms available in the harness, and it is recommended that one of these be used.

3.0 Setting up the client

3.1 Install Java JDK

Install a Java 6 or greater JDK on each client.

NOTE: The Java runtime environment that comes with many Linux distributions may not work with the SPEC virt_sc harness. It is recommended that you install another version of Java that meets the 1.6 version minimum and ensure you are using the correct version by issuing:

java -version

3.2 Set up client hostnames

Entries need to be set up in the client's hosts file (or equivalent) to associate the hostnames the SPEC virt_sc harness uses to the appropriate IP addresses.

Web workload
Harness hostname defaults used:
infraserver - the server that acts as the Backend Simulator (BeSim) for the web workload.
webserver - the server where the HTTP application is running

If you need to use a different hostname than the default then modify the WEB_SERVER parameter in the SPECweb2005/Test.config file accordingly once you have installed the SPEC virt_sc harness.

Note: We recommend dedicating a separate client to run only the webserver workload. See Appendix B in the SPEC virt_sc Client Harness User's Guide for details.

IMAP workload
Harness hostname default used:
mailserver - the server where the IMAP application is running

If you need to use a different hostname than the default then modify the IMAP_SERVER parameter in the SPECimap/IMAP_config.rc file accordingly once you have installed the SPEC virt_sc harness.

Appserver workload
Harness hostname defaults used:
specdelivery, appserver - the server where the application server is running
specemulator - the server where the emulator app is running (for SPEC virt_sc this IP is the same as specdelivery)
specdb, dbserver - the server where the database is running

If you need to use different hostnames than the defaults then refer to the SPECjAppServer2004 User's Guide document.

Batch server workload

Harness hostname default used:
batchserver - the server where the batch server is running

If you need to use a different hostname than the default then modify the BATCH_SERVER parameter in the SPECbatch/Test.config file accordingly once you have installed the SPEC virt_sc harness.

As an example, your hosts file entries should look something like this:

192.168.1.11 infraserver
192.168.1.12 webserver
192.168.1.13 mailserver
192.168.1.14 dbserver specdb
192.168.1.15 appserver specdelivery specemulator
192.168.1.16 batchserver

3.3 VM and client operating system tuning

Running a SPEC virt_sc tile from a client probably requires that certain operating system tuning be done in the following areas:

User Limits
If the operating system has any limits placed on the login session being used to run the SPEC virt_sc loads then those limits may need to be increased to successfully complete a full SPEC virt_sc benchmark run. For example, the following may need to be increased:
  • Number of open files allowed by the user (ulimit -n)
  • Number of processes (ulimit -u)
Networking
Operating system default network tunings may need to be increased to facilitate the web workload. For example, the following may need to be increased:
  • Transmit buffers
  • Receive buffers
See submissions at SPEC virt_sc 2013 Results page for more detailed VM and client tuning.

3.4 Setup SPEC virt_sc harness

See the SPEC virt_sc Client Harness User's Guide for instructions on installing, configuring, and running the SPEC virt_sc harness.

Appendix A - How to Build BeSIM

Instructions for building BeSim on the infraserver follow.

A.1 UNIX/LINUX

To get name of the operating system (for example, HP-UX):

uname -s

In the Makefiles directory use one of the MakeIncl.<type>.<OS> files as a template for your  MakeIncl.<type>.<your_OS> and update to match your environment.
 
To build the FastCGI version of BeSim: 

make fcgi
 
To build the NSAPI version of BeSim:  

make nsapi
 
To build the Zeus ISAPI version of BeSim:

make zisapi
 
Optionally you can specify other make targets by adding TARGET='list of targets'. For example:
 
make zisapi TARGET='clean'
make nsapi TARGET='clean all install' 

The install target uses the path specified by DEST to install the BeSim executable or library, so it should be set to the appropriate place on your BeSim webserver directory tree (i.e. /www/fast-cgi ).
 
If you plan to use FastCGI you must build and install the FastCGI development kit which provides the fast-cgi library and include files before building BeSim. If using Apache for the BeSim webserver, include mod_fastcgi.
Note: Please send any new or updated MakeIncl.* files you want included in a future release to web2005(at)spec.org.

A.2 Windows

Project files are included as an example: BeSim.def, BeSim.dsp, BeSim.dsw

Appendix B - Installing BeSim as a FastCGI for the Apache HTTP Server

There are two pieces necessary to get BeSim for FastCGI working properly under Apache:
  1. Compiling the FastCGI source code and BeSim
  2. Compiling/configuring mod_fastcgi, an Apache module to invoke FastCGI for specific directories

B.1 FastCGI source compilation

Compile the FastCGI source code. The source tree is used on a BeSim (or full) installation of SPECweb2005. To compile it:

cd <path_to_SPECweb2005>/Besim/fcgi-2.4.0/
./configure --libdir=/usr/lib64
make
make install

Note: --libdir=/usr/lib64 was added above due to the default FastCGI Makefile installing libraries to /usr/local, which is not a default library path on Linux and could cause this error upon execution of the FastCGI:

besim_fcgi.fcgi: error while loading shared libraries:
libfcgi.so.0: cannot open shared object file: No such file or directory

Create a directory for the BeSim FastCGI within your web server directory hierarchy (but preferably outside the document root).  Here are some recommended locations for different setups:

SuSE: /srv/www/fcgi-bin
Red Hat: /var/www/fcgi-bin
Apache 2.x compiled from source: /usr/local/apache2/fcgi-bin

Compile BeSim as a FastCGI (replace /var/www/fcgi-bin/ with the directory created in the previous step):

cd <SPECweb2005>/Besim/make fcgi TARGET='clean all install' DEST=/var/www/fcgi-bin/

This creates besim_fcgi.fcgi and install it into DEST.  If not, check the make output for errors.

B.2 Apache FastCGI Web server module: mod_fastcgi

These instructions show how to compile the FastCGI web server module for Apache (mod_fastcgi). For other web servers, please refer to their documentation to see whether FastCGI support is available.

Note for SuSE: SUSE Linux (8.1 and above) ships with a precompiled mod_fastcgi for Apache 2.x.  To check if it is installed, issue:

rpm -q apache2-mod_fastcgi

If it's not installed, install this package from the CDs (see your OS documentation for more instructions).  If this package is installed, you can skip the rest of this section.

Note for Red Hat: If using the httpd package that ships with the distribution, the httpd-devel RPM must also be installed as it contains the necessary utilities and headers to compile Apache modules. To check, issue:

rpm -q httpd-devel

Follow the directions in the INSTALL document (INSTALL.AP2 for Apache 2.x).

Note: As INSTALL.AP2 states, unless you are compiling from source, you need to modify top_dir in your make command. For example, Red Hat users should use the following 'make install' command:

make top_dir=/usr/httpd install

You should now have a mod_fastcgi.so in your Apache modules directory:

Red Hat:

ls -l /usr/lib/httpd/mod_fastcgi.so
-rwxr-xr-x 1 root root 161408 Sep 16 13:47 /usr/lib/httpd/modules/mod_fastcgi.so

Compiled from source: 

ls -l /usr/local/apache2/modules/mod_fastcgi.so
-rwxr-xr-x 1 root root 156434 Sep 21 10:03 /usr/local/apache2/modules/mod_fastcgi.so

Create a directory for FastCGI to store Unix socket files, and change the permissions so the web server can have full access to it:

Red Hat:

mkdir -p /etc/httpd/fastcgi
chmod 777 /etc/httpd/fastcgi

Apache 2.x from source:

mkdir -p /usr/local/apache2/fastcgi
chmod 777 /usr/local/apache2/fastcgi
 
Add support for handling FastCGIs by making the following changes to httpd.conf (for Red Hat, this is in /etc/httpd/conf/):
  1. Add this line in the "Dynamic Shared Object (DSO) Support" section:

    LoadModule fastcgi_module modules/mod_fastcgi.so

  2.   Add the following lines just after the ScriptAlias /cgi-bin/ line:

    ScriptAlias /fcgi-bin/ "/var/www/fcgi-bin/" # <fcgi-bin directory from Section 1, Step 2>
    FastCgiIpcDir /etc/httpd/fastcgi # <FastCGI directory from previous step>

    Note: Replace /var/www and /etc/httpd with /usr/local/apache2 if compiling from source. 

  3. Add the following section, preferably after the <Directory "<CGIDIR>/cgi-bin"> section:

    <Directory "<CGIDIR>/fcgi-bin"> # <fcgi-bin directory from Section 1, Step 2>
        AllowOverride None
        Options +ExecCGI -Includes
        SetHandler fastcgi-script
        Order allow,deny
        Allow from all
    </Directory>
    AddHandler fastcgi-script fcgi

B.3 Testing the BeSim FastCGI

Start (or restart) your web server.

At the console, monitor your Apache error log to view any errors or warnings during FCGI execution, i.e.

 tail -f <APACHE_ROOT>/logs/error_log

You should initially see some FastCGI initialization messages such as:

[Tues Dec 18 10:36:39 2015] [notice] FastCGI: process manager initialized (pid 25700)

Test the BeSim FastCGI, using the scripts in the subdirectory of the SPECweb2005 installation. See Section 2.2 for examples.

Appendix C - Webserver Encryption Protocols

If your application stack requires TLS, edit /opt/SPECweb2005/Test.config and select from the available TLS protocol versions and ciphers.

The following values are available for the TLS version in SSL_PROTOCOL:
 For example, SSL_PROTOCOL = "TLSv1".

The following values are available for the TLS cipher in SSL_CIPHER:
For example, SSL_CIPHER = "TLS_RSA_WITH_3DES_EDE_CBC_SHA".

NOTE: Not all combinations of encryption protocol version and cipher are valid. You may need to experiment with them.

If you change the values of SSL_PROTOCOL and SSL_CIPHER from the defaults in /opt/SPECweb2005/Test.config, you also need to edit the values of WEB.ENCRYPT_PROTOCOL and WEB.ENCRYPT_CIPHER in /opt/SPECvirt/Testbed.config so that they match as shown below:

/opt/SPECweb2005/Test.config
/opt/SPECvirt/Testbed.config
SSL_PROTOCOL must match WEB.ENCRYPT_PROTOCOL
SSL_CIPHER must match WEB.ENCRYPT_CIPHER
Product and service names mentioned herein may be the trademarks of their respective owners.

Copyright � 2013-2016 Standard Performance Evaluation Corporation (SPEC).

All rights reserved.