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
<VIRTUALIZE_HOME>virtualizecli.sh -startServer -data <WORKSPACE_LOCATION>
Disable Event Monitoring
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 Local Machine node.
2. Clear “Launch event reporting when server starts” 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
For best performance with Virtualize set the following system properties and make a few tweaks to tomcat’s server.xml.
set some jvm properties to give increased memory (at least 4gb) and to use a different garbage collector. Typically you would set this in the TOMCAT_HOME/bin/setenv file
$JAVA_OPTS=-Xms2048m -Xmx4096m -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+UseCompressedOops -XX:NewRatio=1
We also want to make some changes to the server.xml file in TOMCAT_HOME/conf
Find this connector
<Connector URIEncoding="UTF-8" acceptCount="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 count to 2
Also towards the bottom of this same file you will fine the following
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false" />
Change this into:
<!--<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false" /> -->
Basically comment out the valve. This will stop Tomcat from filling up the log location with logging information every time the server is hit
Operating System Configurations:
If using Windows, there are some parameters you can tune in the Registry:
1. Click Start > run > regedit
2. Browse to HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > services > Tcpip > Parameters and set the MaxUserPort to 7FA6 (32678 decimal)
3. Reduce the TcpTimedWaitDelay to 1E (30 decimal)
4. Restart the machine for 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)
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. Important since java threads are processes, 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 used and discarded frequently.
You may need to tune tcp buffers. Based on your network configuration there are several sysctl parameters that can be modified. Refer to http://fasterdata.es.net/host-tuning/linux/ for more information.
Here is a checklist, taking the above topics in mind that you can refer to when debugging performance issues with Virtualize
- Turn off performance profiles and Additional delays in your Virtual assets
- Stop monitoring on all assets
- Turn off event monitoring and Hit statistics at the server level
- Verify MaxThreads is set appriopriatly in server.xml (See above).
- Turn off all logging on the server especially SSL debugging
- Is this on a specific asset? Are other assets performing like before?
- If you have any responders, or datasource rows that are unused can they be disabled or removed completely
- Enable caching on datasources. If not, then we are subject to file system read limitations
- Check for any scripts that the might be in the asset. If they are disabled does the issue go away?
- Are here any Network share drives hosting artifacts?
- Set the proper memory args and garbage collection options
o "-J-Xms4048m -J-Xmx4096m -J-server -J-XX:+UseConcMarkSweepGC -J-XX:+DisableExplicitGC -J-XX:+UseCompressedOops -J-XX:NewRatio=1"
- 9.9.5 has both xml and json support for hierarchical parameterization of literal messages "Parameterized Literal" we recommend switching to this view over Form when possible
- Does this reproduce with the same conditions on another server?
Always Separate Virtualize and Data Repository if Possible
If possible, separate Virtualize and Data Repository. This is important for "future proofing" your
deployment. This becomes especially important:
• When Virtualize and Data Repository eventually compete for resources.
• If bad data repository happens to bring down the machine hosting Data Repository. If Virtualize
and Data Repository are separated, this Data Repository failure won’t take the Virtualize
server down with it.
We are currently performing a survey on Spring usage ... https://surveymonkey.com/r/parasoft-spring-user-survey
This is going to help Parasoft better understand the components people are using within the Spring framework. There are 20 questions but don’t worry, they are quick … and all on one page!
Please submit your completed survey by March 10th. Ten lucky participants will win $100 Amazon gift cards, so please don’t forget to fill in your contact information.
Next week we are going to do a “How to” webinar for Parasoft Virtualize Community Edition.
During this webinar, you will learn how to create and deploy the virtual assets presented during the Community Edition Launch Webinar previously done on 2/14/2017.
· Setup your license and get the latest updates.
· Create a simple mock/stub from an example payload (example: REST/JSON)
· Parameterized asset with a CSV/XLS data source using softlogic
· Control simple performance characteristics of the asset
· Create a virtual asset from traffic (example: SOAP/XML)
· Deploy the asset to a shared server (in Azure)
Please register for Parasoft Virtualize Community Edition - "How to" Webinar on Mar 07, 2017 10:00 AM PST at:
NOTE: this session will be recorded and reposted here.
Mark Lambert - Vice President of Products
Parasoft – Perfecting Software
the same architecture
First the concerns for all Unix based platforms
The bin and lib directories have to have been created
on the run machine in the same directory tree as on the build
machine. So if you were running on a Solaris machine and on
your build machine you have created /usr/local/insure in this
location you should have both of these on your run machine.
In your bin directory the following binaries have to
have been copied from your build machine.
gus insra islave pslic psrcdump
On 64 bit architectures you will also need
Then in your base directory /usr/local/insure in this example.
You will need to make sure that you have a .psrc file with
a runtime license or entries telling it where Licenseserver
is running as well as the various options you want set.
Some platform specific concerns:
On Linux Solaris HP
copy all of Insure's libraries from the lib directory on
the build machine to the lib directory you created on
the run machine.
For Linux or Solaris set the environment variable
LD_LIBRARY_PATH to include the lib directory
For HP set the environment variable SHLIB_PATH to
include the lib directory.
The concerns are if the machines have the same basic oslevel
on both machines to determine if the same thing is returned.
And if they are the same oslevel do they have different libc's
and/or libpthread libraries. Insure creates it's libraries
below what amounts to
<your base insure directory>/lib.aix5/`oslevel`
And if you have one machine that oslevel returns 22.214.171.124 and
one that returns 126.96.36.199 you would merely
cd <your base insure directory>
on both of those machines and you would end up with directories of
<your base insure directory>/lib.aix5/188.8.131.52
<your base insure directory>/lib.aix5/184.108.40.206
and this present's no problem as it only requires that we build
with the correct -blibpath set.
But if machine A and machine B both return the same value
for oslevel and have different libraries installed then the
replacement libraries that insure has to create will not be
However you could workaround this by first configuring
for an individual Developer then
cd <your base insure directory>
cp -R lib.aix5 Developer.lib.aix5
Then Developer would need to set his LIBPATH for anything
that he built with insure like
env LIBPATH=<your base insure directory>/Developer.lib:<your base insure directory>/Developer.lib5/220.127.116.11 ./a.out
First, consider, can you simply install a copy of Insure++
on the target machine and get a runtime license for that
That is by far the easiest approach.
If Visual Studio is not on the target machine, the easiest
way to get Insure++ to successfully install on the target is
to have it first invoke msdev through a network share. e.g. run
\\ahost\shared-C\Program\ Files\Microsoft\ Visual\ Studio\Common\msdev98\bin\msd
and then close DevStudio.
If the network share is still available when Insure++ is
installed, the installation should proceed normally, even
though DevStudio is not technically installed on the target.
If for some reason the above is not acceptable and the two
machines have the same exact OS, proceed with the following steps:
1. Copy the instrumented executables and the pdbs from host to target.
e.g. copy \\ahost\myprogram.exe C:\myprogram.exe ;
copy \\ahost\myprogram.pdb C:\myprogram.pdb
2. Copy required executables from host to target
(note that the directory must be named bin.Win32).:
insure.dll, vahfer.dll InsureSpy.exe gus.exe mspdb60.dll
msdia20.dll or msdia71.dll if using vc7 compiled executables,
insfixreg.exe InsurePanel.exe InsureVc7Addin.dll insure.exe
(insfixreg.exe checks for the existence of InsureVc7AddIn.dll
insure.exe, and InsureSpy).
e.g. copy \\ahost\Program\ Files\Parasoft\Insure++\bin.Win32\Inject.exe C:
3. You will probably also want to copy optional executables from
host to target:
islave.exe psrcdump.exe Insra.exe TCA.exe Inuse.exe inject.exe
4. Copy the ins.reg files from the host to the target.
Note that these must be located in a directory called lib.Win32
that is a sibling directory to the Insure_bin directory.
e.g. copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\Win32\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-5.0\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-6.0\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-7.0\ins.reg
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\MSVC++-7.1\ins.reg
5. When the target machine has any version of Visual Studio installed:
A. Copy the necessary libtql* and tql files from the host.
e.g. copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\libtql*
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\Win32\*.tql
from the command line.
This will create the lrt cache.
6. When the target machine does not have any Visual Studio installed.
A. run insfixreg -nospy -nointegration on the target machine.
B. Copy the contents of the lrt-cache on the host to the target
(note1 that target OS must be the same as the host OS)
(note2- the lrt-cache must be located inside the lib.Win32 directory on the target).
copy \\ahost\Program\ Files\Parasoft\Insure++\lib.Win32\lrt-cache
7. Optionally set gus-cache in the advanced tab of the InsurePanel.exe
e.g. gus_cache C:\gus-cache
8. Run the executable under inject.exe or InsureSpy.exe.
If the target windows OS is different than the host windows OS we may
be able to create the lrt-cache for you but this would only be done for