Deutsch    English
V5.1-C    
 

Engineering Office David Fischer AG - Switzerland

Engineering Office David Fischer AG - the manufacturer of ProxySniffer - is since May 2012 a company of the Apica group. To learn more about the excellent Apica's Web performance services visit www.apicasystem.com
Features| Screenshots| Download| Pure Cloud| Licenses| FAQs| Support| Training| References| Partners| Contact| News


The FAQs was last updated on June 6, 2012.
 
Further FAQs about Licensing
and about
Cloud-based Load Generators.

 
Additional information is provided in the Proxy Sniffer Manuals and in the Blog.

FAQs

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 5 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.
Note: in case if you have installed Proxy Sniffer manually on a Unix-like system without using an installation kit you have only to replace the file prxsniff.jar. After that restart Proxy Sniffer. If the restart fails you should delete the file javaSetup.dat and then try to restart Proxy Sniffer again. Both files, prxsniff.jar as well as javaSetup.dat, are located in your Proxy Sniffer installation directory.

Q: After updating Firefox a newer version the "Firefox Recording Extension" does not longer work.

A: There is a new version of the "Firefox Recording Extension" available which supports Firefox up to version 11 (compatible with all Firefox versions starting from version 3.0). Upgrade instructions: first uninstall the "Firefox Recording Extension" inside your web browser. After that download and install the new version from https://www.proxy-sniffer.com/download/PrxRecExt1.xpi.

Q: Why are my load test jobs restricted to simulate only 5 or 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-----".

Note for Proxy Sniffer version 4.3 or older versions: if you have started Proxy Sniffer (or an Exec Agent) from a command line of a terminal - or by writing your own startup script - you must use the Java option -Xbootclasspath/p:<file path to prxsniff.jar> in order that the data of the Exec Agent License Ticket can be read correctly.

Example of starting an Exec Agent on an Unix-like system from a command line of a terminal:

V4.3 or lower versions:
   export CLASSPATH=.:prxsniff.jar
   nohup java -Xmx768m -Xbootclasspath/p:prxsniff.jar ExecAgent -tz ECT 2>&1 > ExecAgent.log &

V4.4 or higher versions:
   export CLASSPATH=.:prxsniff.jar:iaik_jce_full.jar:iaikPkcs11Provider.jar
   nohup java -Xmx768m ExecAgent -tz ECT 2>&1 > ExecAgent.log &

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 JavaScript code and AJAX, and released by Pop-Up windows.

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 this situation.

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 "Receive Content".
 
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
Internal
Value
Error Description of Processing StateError Explanation
(normal case)
No Step / Not Initialized-1The 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)
0Optional 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 *1The HTTP(S) request failed during the opening of new a network connection to the web server.network problem
Transmit HTTP Request *2The HTTP(S) request failed during the transmission of the HTTP request data.---
Wait for Server Response *3The 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 *4The HTTP(S) request failed while receiving the HTTP response header from the web server.network problem
Receive Content *5The HTTP(S) request failed while receiving the HTTP response content from the web server (HTML data, images, ...)network problem
Close Network Connection6The HTTP(S) request failed while closing the network connection to the web server.---
All Done7The 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.
 
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
 
Windows NT and 2000 - Add the following entries:

MaxFreeTcbs20000(REG_DWORD, decimal)
MaxUserPorts65534(REG_DWORD, decimal)
TcpTimedWaitDelay30(REG_DWORD, decimal)

Microsoft Knowledge Base Article - 120642
 
Windows XP - Add the following entries:

MaxFreeTcbs20000(REG_DWORD, decimal)
TcpTimedWaitDelay30(REG_DWORD, decimal)

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

UNIX-like Systems

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.


  
© 2010, 2011, 2012
Ingenieurbüro David Fischer AG, Switzerland
All Rights reserved.