Installation and Configuration
Recording and Post-Processing of Web Surfing Sessions
Load Test Execution
Installation and Configuration
Q: How can I update the license without reinstalling Proxy Sniffer?
A: You have to update the content of the files prxsniff.key and ExecAgentTicket.dat by using a normal text editor like
notepad.exe or vi. Both files are located in the Proxy Sniffer installation directory. The file prxsniff.key contains
your GUI license key and the File ExecAgentTicket.dat contains your Exec Agent License Ticket. You have to restart
Proxy Sniffer after you have updated your license.
Note: if you do not have an Exec Agent License Ticket for your local system on which the GUI is running you can let the content
of the file ExecAgentTicket.dat empty. In such a case only 20 virtual users can be simulated by your local Exec Agent.
Q: How to upgrade Proxy Sniffer to a newer version?
A: If you have installed Proxy Sniffer by using an installation kit for Windows, Mac OS X or Ubuntu, you have first to uninstall
Proxy Sniffer by calling the corresponding uninstall utility. Your load test data will not be deleted. After that install the new Proxy Sniffer version.
During installation, select the same installation directory that was used in the previous version in order that the content
of your MyTests sub-directory continues to be accessible from the Project Navigator. Ensure that all additional (remote)
Exec Agents are also upgraded to the new Proxy Sniffer Version.
Mixing different Proxy Sniffer versions for the GUI and the (remote) Exec Agents is not supported, and will lead to errors
when starting Load Tests.
Q: Why are my load test jobs restricted to simulate only 20 virtual users?
A: The reason is that the content of the file ExecAgentTicket.dat which contains your Exec Agent License Ticket data cannot
be read or contains invalid data. If you have started Proxy Sniffer in a normal way by clicking on the "Proxy Sniffer Console"
icon, please scroll up inside the Proxy Sniffer Console (the black window with the green text) at the beginning of the output to see
the corresponding error message. Please note that the content of the file ExecAgentTicket.dat must also include the delimiter lines
"-----BEGIN EXEC AGENT LICENSE TICKET-----" and "-----END EXEC AGENT LICENSE TICKET-----".
Q: How can I start an Exec Agent (Load Generator) as a Windows Service?
A: Starting an Exec Agent (load generator) as a Windows service is only recommended on (remote) systems where no
Proxy Sniffer Console is started. As first step, install Proxy Sniffer by running the normal
Windows installation kit, but do not enter a GUI license key during installation: enter only the corresponding Exec Agent License
Ticket data. After installation, call InstallExecAgentService.bat. This script will register the Windows Service
ProxySnifferExecAgent. At the first time - after running this script - you have to start this service manually.
Consider also that you have to reconfigure the firewall in such a way that inbound connections on TCP/IP port 7993 are
enabled. Note for Windows Vista/7/2008 systems: it is necessary that you disable UAC to start this service successfully.
Special notes for uninstalling Proxy Sniffer in such a case: before uninstalling Proxy Sniffer you have first to stop
manually the service ProxySnifferExecAgent. Then deregister the service by calling UninstallExecAgentService.bat.
After that you can continue to uninstall Proxy Sniffer in the normal way.
Q: Where I can register additional Exec Agents in the GUI?
A: From the Main Menu, call first the "Project Navigator", and after that click on the "Network" icon at the top
of the "Project Navigator" window which will open the "Exec Agent Network Configuration" window.
Q: What kinds of network protocols are supported for transferring load test jobs to external Exec Agents?
A: For internal communication between the GUI and the Exec Agents, plain TCP/IP network connections as well as HTTP/S tunneling is supported.
Usually the Exec Agents are listening on plain TCP/IP port 7993 - or on port 80 / 443 when HTTP / HTTPS is used for internal communication.
Q: How can I change the root directory of the Project Navigator?
A: Modify the content of the file mytests.dat inside the installation directory. Then
restart Proxy Sniffer and clear all cookies of your web browser.
Hint: the root directory of the Project Navigator can also point to a directory of a file share in order that
several users of the Proxy Sniffer product have access to the same data.
Q: How can I change the default time zone?
A: Modify the content of the file prxsniff.dat inside the installation directory. Then
restart Proxy Sniffer and clear all cookies of your web browser.
Q: Why I get the error "AWS Error Message: Request has expired" when trying to access the Amazon EC2 Service from the Proxy Sniffer GUI?
A: Please check the system clock on your computer. The date sent from your local computer must be within 15 minutes of the Amazon clock or you will get an error like this.
Q: How to remove Proxy Sniffer completely from a computer?
A: If you have installed Proxy Sniffer by using an installation kit, please call first the corresponding uninstall utility.
However the uninstall utility does not delete your license data and it does also not delete your load test programs and
your load test results. After running the uninstall utility, you have additionally to delete the Proxy Sniffer installation directory
manually in order that everything is uninstalled.
Recording and Post-Processing of Web Surfing Sessions
Q: Which web browser products are supported for recording of web surfing sessions?
A: Every web browser product is supported (Microsoft Internet Explorer, Firefox, Safari, ..).
For recording of a web surfing session you have only to modify the Proxy Settings of your web browser.
If you are using Firefox you can also install our Firefox Add-On named "Firefox Recording Extension" which allows you to record web surfing
session in a more convenient way.
Q: Which web browser products can be emulated during a load test?
A: In our opinion, this is a wrong question. In opposite to many other products - Proxy Sniffer emulates
during a load test exactly
the traffic of the web browser product with which one the web session has been recorded. So if you use for example
a German Mozilla V1.0 web browser for recording, a German Mozilla V1.0 web browser is emulated during the load test - with all of its
specific traffic. This may be a big benefit if the web server delivers browser-specific content.
Many other products are only able to record web surfing sessions with a modified Microsoft browser which is not the same.
Please note that altering only the HTTP header field "User Agent" (this is what they do) for emulating another web
browser does not the same because the internal behavior will be still based on the Microsoft browser engine.
Q: What kinds of data are captured during the recording of a web surfing session?
A: Completely all data which are exchanged between the web browser and the web server(s), inclusive exchanged data released by
Q: Is it possible to record a web surfing session over several web servers?
A: Yes. However for testing web portals, it might be a good idea to strip off advertising banners from
external severs by using the filter of the Web Admin GUI or by deleting individual URL calls.
Q: Why does the web browser display a security warning during the recording of a web surfing session for an SSL-encrypted website (HTTPS)?
A: If you record encrypted HTTPS data with Proxy Sniffer, the web browser will display a security alert.
This is "normal" behavior when - and only when - using Proxy Sniffer because the integrated SSL tunnel will decrypt
the data (for recording), and will generate on-the-fly a faked and invalid server certificate.
The format of this warning message depends on the web browser you are using. To continue recording, you must click
one or more times through to the "Continue", "Ignore" or "Confirm Security Exception" button:
Note: Never ignore these kinds of error messages when not recording web sessions with Proxy Sniffer; that is, during normal web surfing.
The apparent secure connection to the web server may actually be insecure, and might be wiretapped or modified by cyber-criminals in
Q: Are session cookies supported?
A: Yes (no special configuration is needed).
Q: How can I handle session specific parameters which are exchanged as CGI or as form values?
A: The GUI based "Variable Finder" and "Variable Handler" menus support to extract session specific parameters from HTTP header fields, from HTML forms, from hyperlinks, from XML ans SOAP data, from JSON data, and by using an integrated GUI based parser from any response content.
The assignment of such extracted values to succeeding URL calls happens automatically. Please take a look at this example. Further information is provided
in the "Users Guide".
Q: How can I assign to each simulated user an own username and password during the execution of a load test?
A: You have to define an "Input File". Please take a look at this example - and please read the corresponding
chapter about Input Files in the "Users Guide".
Q: How can I achieve that some of the simulated users are executing only parts of a web surfing session?
A: You have to define "Inner Loops" which numbers of iterations are controlled by a variable.
The value of such a variable can also be 0 (zero). A value of zero means that a simulated user does not execute (enter) the inner loop.
This can be used in combination with an Input File whose file scope is "new line per user" or "new line per loop" and whose lines contain
values of zero and one which are assigned to the variables of the iterations; that is, some of the users skip parts of the recorded
web surfing session during the load test.
Load Test Execution
Q: What can I do if my generated load test program does not work?
A: In many of such cases the handling of "Dynamically-Exchanged Session Parameters" was not performed in the GUI.
Please read this documentation
and perform the suggested tasks. After that generate the load test program again and try to run your load test once more.
Q: I have recorded a web surfing session which uploads a file - But why does the load test fails?
A: The load test fails because the uploaded file has not been zipped together with the load test program.
You have to copy the uploaded file also into the same "Project Navigator" directory, in which your load test program
is located. After that, you have to ZIP the compiled class (*.class file) of the load test program together with the
uploaded file (and optionally together with your Input Files and Plug-Ins) to one ZIP archive by using the ZIP functionality
inside the "Project Navigator". After that you can start the load test by clicking on the Execute-Icon of the newly
created ZIP archive.
Q: Is it possible to run in parallel several load test jobs which are based on different web surfing sessions?
A: Yes, this is fully supported. The GUI only 'transfers' a load test job to a local or to
a remote Exec Agent (load generator), which allows you to execute an unlimited number of parallel load test jobs at the same time.
Each Exec Agent is also able to execute several load test jobs at the same time.
Nevertheless, the GUI can (but not must) hold a live network connection to each load test job which allows to display real time statistics.
Closing a real time statistic window will not interrupt a load test job.
Q: What is the maximum number of virtual users that can be reached by a load test?
A: The Proxy Sniffer architecture supports to execute high-end load tests with an in reality unlimited number of virtual users.
All product components are fully multithreaded implemented. However, the underlying operating system
of a single Exec Agent (load injector) can be overloaded if too many concurrent virtual users are executed
by the same system. In most common cases of overload, the CPU(s) of an Exec Agent are always
nearly 100% used and the measured response times are in such a case not valid, because the measuring system
by itself is overloaded.
Proxy Sniffer supports therefore to combine an unlimited number of Exec Agents to a cluster,
so that an unlimited number of virtual users can be reached - or in other words, the maximum number
of virtual users is only limited by the power and the number of the Exec Agents. Proxy Sniffer supports to execute
cluster jobs in an absolutely transparent way, and merges automatically the measured results of the
corresponding Exec Agents to an united load test result. Several cluster jobs can run in parallel,
by using the same or a different collection of Exec Agents. Exec Agent Clusters can be composed by using a mixed
collection of local and remote Windows and Unix-like systems.
Q: Why I cannot use my Windows workstation to generate realistic load?
A: Normally, the anti-virus scanner of your Windows workstation intercepts all HTTP(S) connections, but is not capable to scan
the network traffic during a load test when hundreds of web users are simulated. As a result of this you will measure
wrong response times and nonexistent network problems.
Therefore we strongly recommend that you operate the load generators on Unix-Like systems. The scalable and operating system
independent architecture of Proxy Sniffer allows you run the Proxy Sniffer GUI on any operating system (including Windows) and
to use from this GUI load generators which are installed on any other operating system. The most normal case is that the GUI is
installed on one or several Windows workstations, but that the load generators are installed on Unix-like systems.
As a further alternative, you can also use your Windows workstation or dedicated Windows servers as load generators - but only
in case if you are permitted to disable the anti-virus scanner in such a way that no HTTP(S) connections are scanned.
Q: What should be measured?
A: We recommend, that you record a web surfing session which covers the key menus
(most used menus) of the web application and that you execute the same
load test several times by using a different number of concurrent users for each test-run
(1, 2, 5, 10, 20, 50, 100, 200 ...). After that a graphical comparison of the measured
results can be done (so called "Load Curves") which will give you an excellent overview about
the stability and the maximal capacity of the web application:
You should also have a closer look on the response times per web page and within a page to
the response time per URL to isolate the top-time consuming URLs. If you encounter big
differences between the URL response times - which are more or less size independent - you have
found valuable candidates for a server-sided tuning.
You will obtain a lot of additional information by examining the detail results of each test-run.
Up to 19 different diagrams and statistics are available. Example - composition of slowest URL calls:
To detect memory and resource leeks at server side we recommend that you additionally perform an endurance test over a couple
of hours by using a moderate number of concurrent users.
Q: How can I easily determine if the network is the reason for slow response times?
A: Whatever somebody is trying to tell you - the network throughput is commonly not the reason for slow response times.
We suggest that you compare the response time of a bigger static image ore a style sheet with the response time
of a server side generated HTML page which has approximately the same size. For example: if a image of 20 kBytes
size has been received within 200 Milliseconds, but a server side generated HTML page with a size of 30 kBytes
takes 5 Seconds, the network is definitively not the reason that the server side generated
html page has a slow response time. There must be an other reason which is outside the network, commonly found
inside the web server.
Q: What can be done if embedded images are slowly displayed?
A: If the text of a web page is received within a moderate response time, but the embedded images are
displayed slowly bit by bit, it might be that the keep-alive option has been disabled at server side or
a downgrade to the older HTTP protocol version 1.0 is forced by the web server - instead of using
the newer HTTP protocol version 1.1. You can check this by selecting the "HTTP Keep-Alive Efficiency"
diagram on the result details menu of a test-run:
If the rate of the "Successful Recycled Network Connections" is less than 70% - or if only "New Created Network Connections"
have been measured, the web server is wrong configured and you should try to enable its keep-alive option.
Thereafter you should measure the web server again to check if it performs better. We recommend that the
keep-alive timeout is configured within a range of 7-15 Seconds.
Q: If a response timeout is measured - or when slow response times are measured: How can I determine exactly if this is a network problem or because if the web application responds too slowly?
A: During the execution of each HTTP(S) request the "internal processing states" of the HTTP(S) request are also captured by Proxy Sniffer.
In case of a response timeout - or when slow response times are measured - such an error is only a network problem (firewall, rooter,
insufficient network throughput, loss of TCP/IP packets) if the error occurs at the internal HTTP(S) processing states "Open Network Connection", or "Receive HTTP Header", or
If a response timeout or slow response times are measured at the HTTP(S) processing state "Wait for Server Response" the error
occurred because the web application responds too slowly (the most normal case).
The following "internal processing states" of each HTTP(S) request are measured by Proxy Sniffer:
|Internal Processing State|
of HTTP(S) Request
|Error Description of Processing State||Error Explanation|
|No Step / Not Initialized||-1||The HTTP(S) request had not yet started.||---|
|Open Network Connection to Proxy|
(This processing state is only used
if the load test is performed via
an outbound proxy)
|0||Optional state: The HTTP(S) request failed during the opening of new a network connection to the outbound proxy server of your company.||network problem inside your company - or on the outbound proxy|
|Open Network Connection *||1||The HTTP(S) request failed during the opening of new a network connection to the web server.||network problem|
|Transmit HTTP Request *||2||The HTTP(S) request failed during the transmission of the HTTP request data.||---|
|Wait for Server Response *||3||The HTTP(S) request failed while waiting for the first byte of the HTTP response header data from the web server.||the web application responds too slowly|
|Receive HTTP Header *||4||The HTTP(S) request failed while receiving the HTTP response header from the web server.||network problem|
|Receive Content *||5||The HTTP(S) request failed while receiving the HTTP response content from the web server (HTML data, images, ...)||network problem|
|Close Network Connection||6||The HTTP(S) request failed while closing the network connection to the web server.||---|
|All Done||7||The HTTP(S) request itself completed successfully (all data have been transmitted and received), but the received HTTP status code was incorrect, or the received MIME type (text/html, image/gif, ...) was incorrect, or an error was detected inside the received content data.||malformed response content (unstable web application)|
* = The time elapsed in milliseconds for the corresponding processing state is also captured by Proxy Sniffer if no error occurs - for each successful executed HTTP(S) request.
Q: What means the error type "Network Error at Client Side"?
A: You are out of free client sockets (free network connections) on your load generator (Exec Agent) and you have to
tune the TCP/IP configuration of the operating system on the load generator. This may happen especially on Windows systems - or if the load test uses the older
HTTP V1.0 protocol - or when the web application server does not support "keep-alive" and therefore network connections can not be reused or recycled.
This may also happen if the web application performs very well and therefore the load initiating system is using a lot of new network
connections within a short time.
Action: add the following new entries with regedit on your load initiating system. Afterwards
you must reboot the system.
Windows NT and 2000 - Add the following entries:
Microsoft Knowledge Base Article - 120642
Windows XP - Add the following entries:
Microsoft Knowledge Base Article - 314053
Windows 2003 Server - Add the following entries:
|SynAttackProtect ¹||0||(REG_DWORD, decimal)|
|TcpTimedWaitDelay *||30||(REG_DWORD, decimal)|
|MaxFreeTcbs *||20000||(REG_DWORD, decimal)|
|MaxUserPort *||65534||(REG_DWORD, decimal), inconsistent Microsoft documentation|
|MaxUserPorts *||65534||(REG_DWORD, decimal), inconsistent Microsoft documentation|
* client and server side tuning suggestions
¹ additional server side tuning suggestion
Windows 2008 Server - Add the following entry:
|TcpTimedWaitDelay *||30||(REG_DWORD, decimal)|
* client and server side tuning suggestion
In addition we recommend that you execute the following command from a terminal window:
netsh int ipv4 set dynamicport tcp start=12288 num=53247
This problem usually does not occur on Unix-like systems: you can check with "ulimit -n" the number of
maximal available file and network connections per process. Increasing this value can be done
with "ulimit -n <number>". Example (recommended value): "ulimit -n 16384". This has to be done before a Proxy Sniffer Exec Agent process is started.