Performance Tuning Checklist

1. Turn off event monitoring and hit statistics at the server level. (See Disable Event Monitoring and Hits Statistics.)
2. Configure the Tomcat connector settings. (See Tomcat Configurations.)
3. Set log level to INFO and disable JVM level debug logging, e.g. SSL debugging.
4. Enable caching on data sources. Otherwise, data sources will be subject to file system read limitations.
5. Increase JVM heap memory and apply garbage collection options. (See Configuring System Properties)
6. Use Literal view instead of Form view whenever possible. Hierarchical parameterization is supported in literal views.

Configurations for Best Performance

For best performance when using a Virtualize server, we recommend the following configurations:

Always Run your Server in "Headless Mode"

You can do this utilizing the soavirt.war deployable in a web server like Tomcat or launching your Virtualize application with the virtualizecli executable.

Example:

virtualizecli.sh -startServer -data <WORKSPACE_LOCATION>

Disable Event Monitoring and Hit Statistics

Always stop monitoring Virtual Assets—both on the server and on all workstations—before starting a load test.
You can also completely disable monitoring as follows:

1. In the Virtualize Server view, double-click the desired server node.
2. In the Server Configuration tab, clear the "Enable the event monitoring service" and the "Enable the statistics collection service" checkbox and save.
3. Stop and re-start the server.

This can also be done from the Continuous Testing Platforms Servers Page for headless deployments.

Tomcat Configurations

For best performance with Virtualize, set the following system properties and make a few modifications to the Tomcat’s server.xml.

Configuring System Properties

Set JVM properties on start-up to increase the heap memory (at least 4gb) and change the garbage collector.

For Virtualizecli:

virtualizecli.sh -startServer -data <WORKSPACE_LOCATION> -J-Xms2048m -J-Xmx4096m -J-server -J-XX:+DisableExplicitGC -J-XX:+UseCompressedOops -J-XX:NewRatio=1

For WAR deployment (configured in the <TOMCAT_HOME>/bin/setenv file):

JAVA_OPTS=-Xms2048m -Xmx4096m -XX:+DisableExplicitGC -XX:+UseCompressedOops -XX:NewRatio=1

Configuring server.xml

1. Locate the HTTP Connector element in the server.xml file located under the <TOMCAT_HOME>/conf folder. The default connector port is 9080 for virtualizecli and 8080 for a WAR deployed in Tomcat.
2. Add/update the acceptorThreadCount, enableLookups,and maxThreads attributes as shown in the following:

   Example:
   

   <Connector URIEncoding="UTF-8" acceptorThreadCount="2" connectionTimeout="20000" enableLookups="false" maxThreads="750" name="default" port="9080" protocol="HTTP/1.1" redirectPort="9443" server="Parasoft Server"/>

   This tells Tomcat to keep a processing thread pool of 750 threads. It also sets the acceptor thread count to 2 and disables DNS lookups.

3. Locate the Valve element toward the bottom of the file.

4. Comment out the Valve element as shown in the following:
   Example:

   <!--<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false" /> -->

This will stop Tomcat from filling up the log location with logging information every time the server is hit.

Operating System Configurations

Windows

If using Windows, there are some parameters you can tune in the Registry:

1. Click Start > run > regedit.

2. Navigate to the following registry key: 
   

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3. Right-click “Parameters” and choose New > DWORD.
4. Name the value "MaxUserPort" and update its value data to "7FA6" (hexadecimal) or "32678" (decimal).
5. Right-click "Parameters" and choose New > DWORD.
6. Name the value "TcpTimedWaitDelay" and update its value data to "1E" (hexadecimal) or "30" (decimal).
7. Restart the machine for the changes to take effect.

This will increase the number of allowed concurrent TCP connections in Windows (MaxUserPort), and reduce the amount of time that an unused TCP port is reserved before it can be reused (TcpTimedWaitDelay).

Linux

It may be necessary to tune your Linux server for high throughput. The following are some system settings that could be helpful. These should be applied to Virtualize and the load generation tool.

ulimit -u 4096

Sets the maximum number of processes available for a single user. This is important because java threads are processes and having this number too low could result in the inability to spawn new threads.

sysctl -w net.ipv4.tcp_tw_reuse=1  
sysctl -w net.ipv4.tcp_tw_recycle=1

These allow the operating system to quickly reuse and recycle network sockets. This is important while under heavy load as sockets can be used and discarded frequently.

sysctl.conf

You may need to tune tcp buffers. Several sysctl parameters can be modified based on your network configuration.  Refer to Linux Tuning documentation for more information.

Virtualize and Data Repository Deployments

It is recommended to minimize the network latency between a Virtualize server and a Data Repository server as much as possible. Network latency between the processes can negatively impact the performance of the Virtualize server under load, and the most common way users accomplish this is by installing them on the same machine, or two machines that are co-located as much as possible (e.g. same data center region). The Data Repository server can consume a large amount of memory, so when installing it on the same machine as a Virtualize server, it is advised that the machine have at least 32GB RAM (see Deployment Recommendations).

Debugging Checklist 

1. Turn off performance profiles and additional delays in your Virtual assets.
2. Is the issue related to a specific asset? Are other assets performing like before?
3. If you have any responders or data source rows that are unused, can they be disabled or removed completely?
4. Check for any scripts that might be in the asset. If they are disabled, does the issue go away?
5. Are there any Network share drives hosting artifacts?
6. Does the issue reproduce with the same conditions on another server?