|
|
 |
 |
| Support |
|
|
| Professional Edition |
Please send your support questions by E-Mail to direct@d-fischer.com.
Where possible, include a telephone number where we can reach you for information. In order for us to assist
you quickly and efficiently, include in the E-Mail all relevant information; for example, your load test
recordings (*.prxdat files), printscreens, log files, and measured test results (*.prxres files).
|
| FAQs |
|
|
Licensing
Installation
Technical Questions
Load Test Execution
Q: Where I can purchase Proxy Sniffer?
A: You can purchase Proxy Sniffer only from us and from of our partners.
Q: What kinds of license types are available?
A: Proxy Sniffer license keys are commonly bound to the TCP/IP address or alternatively bound to the host name
of the load initiating system (load source). Generic license keys which can be used for any computer
are also available for order (site license).
Q: How is the price model for the Proxy Sniffer license?
A: Our price model is only based on the number of load initiating CPUs (load sources). The Professional Edition contains
no restrictions about the number of simulated, parallel users during a load test.
Q: How much is a Proxy Sniffer license?
A: You will find this information here. We are sure to give you one of the best price/performance ratio ever seen for a professional
web load and stress testing tool.
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.
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: How can I extend the CLASSPATH so that own libraries can be used during a load test?
A: Please take a look at the user's guide, chapter 12.1.
Q: How to install an external Exec Agent on a Unix system for remote job execution?
A: Please take a look at the application reference manual, chapter 3.5 and 3.6.
Q: How to start a load test job on an external Exec Agent?
A: Please take a look at the user's guide, chapter 10.2.
Q: What kinds of network protocols are supported for transferring load test jobs to external Exec Agents?
A: Plain tcp/ip based network connections as well as HTTP/S tunneling is supported. HTTP/S tunneling over
outgoing proxy servers is also supported.
Q: Which web browser products are supported for web session recording?
A: All web browser products.
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 kind of data are captured during recording a web surfing session?
A: Completely all data which have been exchanged between the web browser and the web server, including all request
and response headers and all exchanged content data.
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: Are session cookies supported?
A: Yes (no special configuration is needed).
Q: What happens if session specific parameters are exchanged as CGI or form values instead of using session cookies?
A: This is not a problem. The GUI based variable handler supports extracting session specific parameters from forms and from hyperlinks
and assigning such extracted values to succeeding url calls.
Q: Is it possible to use values from input files as CGI or form parameters during a load test?
A: Yes - this is easily configurable on the GUI by using the variable handler. In example, applying an own username
and password per concurrent user as logon parameter.
Q: The compilation of a load test program fails with java.lang.ClassFormatError: Code of a method longer than 65535 bytes
A: Generate the load test program again by using the "large code model" option.
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 'queues' a load test job to a local or to
a remote Exec Agent (load injector), which allows to execute an unlimited number of parallel load test jobs at the same time.
Each Exec Agent is able to execute several load test jobs at the same time by using an own Java virtual CPU for each job.
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 systems.
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 ...). Thereafter a graphical comparison of the measured
data can be done 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.
More than 10 different diagrams and statistics are available:
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 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. In 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 "Recycle Network Connection Rate"
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: What means the error type "Network Error at Client Side"?
A: You are out of free client sockets on your load initiating system (load source) and you have to
tune the TCP/IP configuration of the system. This may happen especially on Windows systems if the load test uses the older
HTTP V1.0 protocol - or when the 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/2000 - Add the following entries:
| MaxFreeTcbs | 20000 | (REG_DWORD, decimal) |
| MaxUserPorts | 65534 | (REG_DWORD, decimal) |
| TcpTimedWaitDelay | 30 | (REG_DWORD, decimal) |
Microsoft Knowledge Base Article - 120642
Windows XP - Add the following entries:
| MaxFreeTcbs | 20000 | (REG_DWORD, decimal) |
| TcpTimedWaitDelay | 30 | (REG_DWORD, decimal) |
Microsoft Knowledge Base Article - 314053
Windows XP with Service Pack 2
Additionally to the suggestions above you should install the patch from
http://www.lvllord.de. We recommend to increase the number of half-open concurrent network connections per
host to a value of 500-5000.
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), inkonsistent Microsoft documentation |
| MaxUserPorts * | 65534 | (REG_DWORD, decimal), inkonsistent Microsoft documentation |
* client and server server side tuning suggestions
¹ additional server server side tuning suggestion.
TCP/IP Configuration Parameters
UNIX Systems
This problem usually does not occur on Unix systems: you can check with "ulimit -n" the number of
maximal available file and network connections (tcp/ip sockets) per process. Increasing this value can be done
with "ulimit -n <number>". Example: "ulimit -n 4096". This has to be done before a Proxy Sniffer Exec Agent process is started.
If you are running load tests with hundreds or thousands of concurrent users we recommend
that you follow the suggestions of the BEA WebLogic site: Tuning Hardware, Operating System, and Network Performance.
These tuning suggestions should be applied on client side as well as on server side. The same suggestions can be applied for other web application servers like Sun ONE, IBM WebSphere, Oracle IAS, JBoss, Tomcat or Apache.
Q: I got a lot of network connection failures during a HTTPS load test
A: This may occur if the web server uses OpenSSL/mod_ssl. Some OpenSSL/mod_ssl releases
are unstable under
load. It is also recommended that you do not configure the following
mod_ssl option on the web server:
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
As far as we know, this was only a workaround for the Microsoft Internet Explorer V4.x which nearly nobody
still uses. Downgrading to the HTTP V1.0 protocol and turning off keepalive at the server - in combination with HTTPS -
has a negative impact to the performance. Please note that the other workarounds for
the Microsoft Internet Explorer V5.x should be configured as OpenSSL suggests.
Q: Recording a HTTPS session works, but the load test program always fails immediately with "network connection aborted"
A:
Inside all SSL implementations are a lot of hidden incompatibilities and bugs. Neither the OpenSSL library as well as other SSL libraries
from commercial manufacturers are really 100% compatible. For this, Proxy Sniffer records HTTPS web surfing sessions in high compatibility mode, but tries to
execute load tests with a lower compatibility mode - which is a little bit faster and saves resources on the local system when a test is executed
with more than 100 concurrent users.
Workaround: please enable the high SSL compatibility mode for load test execution by entering
-sslcmode as additional option at the start
load test job menu.
|
|
|
|
