Frequently Asked Questions

• How can I purchase licenses for JBlitz ? What sort of support and upgrade options do you offer ?
• Is JBlitz 5.1 backward compatible with JBlitz 5.0 and 4.x ? What should I watch out for if I upgrade ?
• Do you give out the source code ?

• What are the limitations of the evaluation version of JBlitz ?
• Why does the pause time between requests not reduce to zero when I run at full throttle (+100) ?

• What types of testing can JBlitz perform ?
• What types of software can JBlitz test ?
• What is the mechanism by which JBlitz captures test configurations ?
• Can JBlitz handle POST requests. How do I specify the POST (form) data ?
• We have a page which does a database search based on a name parameter. Can we test this with JBlitz ?
• How can we verify the accuracy of each returned web page ?
• How can I test a SOAP request using JBlitz ?
• Our web application accepts a variety of XML format requests. Can JBlitz test all of the request types ?
• How do we maintain server side session state with JBlitz ?
• Is there any way to see the actual HTTP requests being made by JBlitz ?
• How can we schedule our nightly tests with JBlitz ?
• Can we have JBlitz run our tests silently and without any GUI (from a command prompt)?
• How does JBlitz store the configuration for each test setup ? Can we copy and edit this information ?
• Does JBlitz handle SSL ?
• How do we configure JBlitz to use our private / test SSL certificate ?
• Can we configure JBlitz to use sub-domains on some pages ?
• Can JBlitz transfer session IDs encoded within our URLs ?
• Does JBlitz support NTLM authentication ?
• How do we configure JBlitz to use our proxy server ?
• Can JBlitz handle form based authentication ?
• How can we effectively measure response versus load ?
• What reporting capabilities does JBlitz have ?

• When you say JBlitz is a Java application, what difference does that make ?
• Can we change the Java Look And Feel that is used by JBlitz ?
• Sometimes it appears that our test machine cannot maintain enough connections to the server. Is there anything we can do to alleviate this ?
• What system specification recommendations do you offer ?
• How can we minimize the amount of memory that JBlitz needs at runtime ?
• Can we use a JVM different from Sun's JVM 1.6, 1.5 or 1.4 ?

• Is there a known bug list ? - yes look here...
• Connection problems may occur on some versions of Windows or when certain request headers are used
• Error message 'unable to find valid certificate path' is received when using a https request with a self-signed or test certificate

Visit our Software Store to purchase a license for JBlitz. Regular licenses, multi-installation licenses and site licenses can all be purchased online. The full version of JBlitz will be made available to you by internet download.

All license types allow you, for each installation, to run up to 500 virtual users per test case and up to 500 test cases. Note, however, that the practicable number of virtual users you can test with will be influenced by the configuration of your test machine, its CPU speed and the amount of memory available to JBlitz, amongst other things.

Support is email based and covers 180 days from the date of purchase (regular or multi-installation licenses) or 365 days (site licenses). We are, of course, also very happy to help out informally with enquiries and problems at times before and after this period. Just drop us a line.

Minor upgrades (say from 5.0 to 5.1) for JBlitz are available free of charge to all license holders. A minor upgrade is a change in the minor version number.

Major upgrades (say from 5.0 to 6.0) for JBlitz are available free of charge to site license holders, but not to regular license holders. The latter can normally purchase major upgrades at a discounted price, but this is not guaranteed and the availability depends on the circumstances at the time.

For any sales enquiries or questions, please email one of our sales team and we'll be happy to help.

Yes, generally speaking, JBlitz 5.1 will run test configurations used by the previous JBlitz 5.0 and 4.x versions. There are some things to watch out for, however, principally the changes made to the dynamic substitutions that may be embedded within your test URLs. Take a look at our compatibility page for more detailed information.

The version history will also provide background information on what has changed from JBlitz 4.2 to JBlitz 5.0 / 5.1. 

We are not currently licensing any of the source code. We may change our position on this in the future. Contact us if you are interested.

The free trial version of JBlitz is functionally identical to the retail version except for the following noted areas:

• It expires after 30 days from the date of first use.
• It is limited to 3 test cases with a maximum of 20 virtual users each.
• The maximum run time is 10 minutes. The evaluation version of JBlitz will load test for 10 minutes and no more.
• The minimum pause time between requests is limited to 2000ms. This is at neutral throttle. This pause time can be reduced from 2000ms to 1000ms (but no lower) at higher throttles.
• The test scheduler can only schedule a single test configuration. Multiple configurations can be run back to back in the retail version.
• The evaluation version is not supported. Feedback and comments are welcome, but no bug fixes, patches or any other type of support is provided.

At neutral throttle, the minimum pause time for the evaluation version of JBlitz is 2000ms. When the throttle is increased, the pause time reduces, but the evaluation version still enforces an absolute minimum of 1000ms. The retail version of JBlitz has no such limitations.

If the absolute minimum of 1000ms is met, the value that would otherwise be used in the retail version is shown in parentheses underneath the arrow icons.

JBlitz can help you carry out the following types of testing:

Stress testing		checking for robustness and integrity under continuous heavy load
Performance testing		monitoring how the number of users affects responsiveness and throughput
Functional testing		validating functional areas within your website or web application
Resource usage testing		examining any changes to resource usage on the server with time or increased loading. For instance, the server may use more and more memory over time without freeing it up properly
Endurance testing		testing the correct functioning and maintained performance over a prolonged period of continuous loading
Overload testing		seeing how many simultaneous users your website or web application can handle before either it falls over or it performs so slowly as to become unusable
Quality assurance testing		assessing any changes in behavior of your website or web application after software or hardware changes

If you're designing, writing or testing a dynamic website or web enabled application, then JBlitz should be of serious interest to you. These applications often include complex technologies such as ASP, JSP, servlets, EJBs, Perl and CGI scripts. All of these technologies need to be carefully tested when your site / app is under load or continuous use. These technologies are often sensitive to loading and they may not scale, They are often complex to code and easy to introduce bugs into. They often share objects, resources or functions which need to be safeguarded against concurrent access (a good example is a database connection pool). And these technologies are most often used on sites where problems, bugs and defects can be expensive and embarrassing (i.e. e-commerce websites).

JBlitz is ideal for testing anything that is web enabled:

• Websites
• Web enabled applications
• Server side software components accessible via a web front end
• Web services

The rule is that if you are writing a website, or if your application has a web front end (i.e. it is web enabled), then you can test it with JBlitz. JBlitz works with URLs just like a browser, so if you can exercise your software via a web browser, then chances are you can stress and performance test it with JBlitz.

JBlitz issues requests using the HTTP/1.0 protocol with either the GET or POST request method.

Unlike more expensive tools that record and playback web conversations, we have opted for a simpler approach to capturing test configurations. This approach is based on the assumption that the developer or test engineer knows which key resources and scenarios are the most appropriate to test. Thus, JBlitz allows the engineer to input precisely the resources and parameters to be used at each point in the test. This approach also avoids the need to learn proprietary and complicated scripting languages that other tools often demand.

Of course, realistic testing involves taking the specified test URLs and varying the parameters passed to the web server with each request. JBlitz does this via 'dynamic substitutions'. These are specified as '%' substitution elements embedded in the URLs. JBlitz substitutes values for these elements at test time according to well specified rules. For example, %j is used to specify a randomly generated integer between 0 and 9 inclusive, whilst the elements %x00 to %x99 are used to substitute the contents of a given document into the request line. Substitutions are applied recursively making this feature very powerful and very flexible. For example, you could embed random user names or user ids within XML documents substituted into the request line. Further to this, you could have JBlitz substitute the document randomly from a set of valid 'test' documents.

More information about this is given in the section Defining your test configurations in the product overview.

Yes, in fact, JBlitz handles not only GET and POST requests, but all the common request methods are catered for.

If you specify the POST request method, you can either:

• use the web page editor to specify name value pairs that make up the form data. See the help for more information about using the web page editor.
• type it in manually after a question mark at the end of the URL (as if it were a query string). JBlitz knows to repackage the data after the question mark to make the POST data for the request.
• write your POST data into a file and use a %x file content substitution. JBlitz will POST the contents of the file. Use a URL like /mypage?%x00 and JBlitz will POST the contents of the document pointed to by the %x00 dynamic substitution to the page /mypage. See the help for more information on %x file content substitutions

A typical SOAP request comprises an XML message following on from the normal HTTP headers that exist for any HTTP GET or POST request. For example,

POST /StockQuote HTTP/1.0 Host: www.stockquoteserver.com Content-Type:text/xml SOAPMethodName: Some-Namespace-URI#GetLastTradePrice Content-Length:xxxx <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1"> <SOAP:Body> <m:GetLastTradePrice xmlns:m="Some-Namespace-URI"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP:Body> </SOAP:Envelope>

The request body is made up of the actual SOAP message to transmit. This is basically a HTTP POST request where the SOAP message is the data to POST. A good way to achieve this with JBlitz is to define a %x dynamic substitution that contains the SOAP request body. This simply involves writing the SOAP markup into an XML file and then defining one of the %x dynamic substitutions (in this example %x00) to point to that XML file. Once this is done, a URL similar to the following may be used:

/StockQuote?%x00

Note: in JBlitz, POST data is entered by simply typing it into the URL after a question mark, just as if it were a query string - JBlitz knows that you have marked the request as a POST and repackages any data following the question mark into POST data; see specifying HTTP POST requests for more information.

Yes. Define your XML data in separate files. Then embed the '%x00' to '%x99' dynamic substitutions in your web page request URLs. For example, consider the following web page request

/bookCatalog.jsp?request=%x00

Define the dynamic substitution (under the 'Dynamic Substitutions' tab) %x00 to point to one of the XML test files. JBlitz will then substitute the XML data into the request URL when it runs. You can get JBlitz to URL encode the XML data as required.

Here are some more ideas you can use to refine your test further:

• Recursively apply substitutions. Within your XML test files, you can embed further dynamic substitutions (e.g. use '%j' to generate a number between 0 and 9 inclusive). There are no restrictions on this technique. Have the XML files include other XML files etc). Properly thought through, this can greatly enhance your testing capabilities.
• Use the item substitutions '%y00' to '%y99' to define a selection to be made when JBlitz runs. Use this in conjunction with the XML test files to get JBlitz to choose a random XML test file from a suite. To do this, you'd need to change the request URL to something like '/bookCatalog.jsp?request=%y00' and then define the substitution '%y00' to point to a list of entries defined as '%x00', '%x01', '%x02' that define the actual XML data to send.

When using substitution elements within external files that make up document substitutions, make sure the substitution element does not act recursively or set up closed cycles of substitutions. For example, if the substitution element %x00 references your document 'invoice.xml', make sure that 'invoice.xml' does not itself contain the element '%x00' either directly or indirectly. If it does, you'll need to untick the box 'Do not encode embedded substitutions' so that JBlitz URL encodes the inner reference and does not follow it..

Secondly, you can use the inbuilt debugger to inspect every request message as it is issued, and even to make changes on the fly. Click on the 'Debug' button in the right hand gutter of the main screen. Hit the 'Step Debug' toolbar button to step into the first web page download for the selected test case. You will be able to see each stage of the download process as it occurs and make changes along the way. More information is given in the debugger section of the help file

Lastly, you can use the command line option '-debug http'. This will print the actual HTTP requests being made by JBlitz to the standard output device. Be careful using this option when you have configured more than just a few virtual users as the debug output will become difficult to interpret and will also hinder performance. However, this command line option is ideal when you need to track down unexpected or incorrect responses from your website or web application to any given request.

See the help on command line parameters for more information.

Yes. JBlitz can be configured to run nightly tests using the test runner / scheduler.

Launch JBlitz in the normal way and click on the scheduling icon (clock icon) on the toolbar. Create a new test schedule specifying one or more test configurations to be run and a time to run the tests at. JBlitz will show a timer icon in the top right corner of the screen. Leave JBlitz opened (you can minimize it if you like) and it will run your test(s) at the configured time. 

Come back later and the results will be presented in the scheduler window. Double click on any given line in the results table to review the test outcomes within JBlitz.

Yes. You can use the command line parameter -console to run JBlitz 'in the background' without any GUI

When you use this parameter, you need to have setup your test configuration already so that the tests can be run without any user intervention. By default, JBlitz will run the last configuration that was being used when it is run with the -console command line parameter. You can also specify which test configuration to use by specifying the test configuration on the command line too.

The console mode support has been beefed up in version 5.1 so that JBlitz will run in a Java 'headless' environment without any issues.

There are two principal ways that you can configure JBlitz to automatically perform the required checks on any given downloaded page.

1. Text searching of each response to ensure the expected data exists. In JBlitz, text searching is configurable at the page level. Bring up the test case settings dialog, select a web page and click on the 'Page Settings' button at the bottom right. Select the 'Errors' tab and click the 'Set' button. Text searching comprises three different types:
   • Plain Text Searches: simple searches for given error or success text within the returned page or its headers.
   • Regular Expression Pattern Finds: evaluation of a Perl-like regular expression against the returned page or its headers. The expression can match on any part of the data.
   • Regular Expression Pattern Matches: entire matching of a Perl-like regular expression to the returned page or its headers. The expression must match the whole data in its entirety.
2. Response checking using your own Java code. A simple means of extending JBlitz to allow your own code to determine whether any given response page or its headers is 'accurate'. The response checker API is a single static method that can be implemented by any Java class and that can be configured for one or more web pages that comprise your test case. Response checkers can check the returned data against the input URL for accuracy of content. They can also check in a more complex way by maintaining state across web page downloads so that the whole 'download path' is checked. They can be as simple or complex as you require and perform the sort of bespoke error checking that only your own custom code can achieve. See the customization help for more information.

Additionally, custom response checking can be performed by a customization module. These modules can register a new or modified query extension with JBlitz that has the ability, amongst other things, to verify any given web page download.

By default, JBlitz will receive and transfer all the necessary cookies that are required to maintain server side state. Typically, this is done using an ASP or JSP session ID cookie that is sent back by the server and which is then re-sent to the server by JBlitz with each subsequent request.

The global settings for controlling state behavior are on the 'State Maintenance' tab on the main screen. Here, you can enable or disable state maintenance via cookies. By default, cookie based state maintenance is enabled.

If the server also sends back the ASP / JSP session ID encoded into URLs within the returned pages, you'll also need to enable the 'Response parsing' check-box and additionally configure how the session ID path parameter is transferred from one page to the next. See the help for more info.

From version 3.0 on, JBlitz incorporates XML based test configuration files which contain all your test settings. Each file is a self contained and user-editable definition of a test environment. You can edit / email and otherwise freely alter the settings within. The only proviso is that the file remains a valid XML document as it has to be parsed before it can be used by JBlitz. Read the help for more.

Yes. JBlitz could be used to effectively test that page. For example, if your page was called 'dblookup.jsp' and accepted a parameter with the name 'search_term', then you might specify the web page in JBlitz like this:

/dblookup.jsp?search_term=%s

Here, the '%s' in the name-value value is dynamically substituted with a random string on each request of that page. The substitution is described here.

As an additional example, say you had another parameter called 'category' which used values such as 'cat0', 'cat1' etc to specify the search category. You could test this page by specifying something like this:

/dblookup.jsp?search_term=%s&category=cat%j

Here the search term is randomly generated and the category is randomly switched between 'cat0', 'cat1' etc (%j chooses a number between 0 and 9 inclusive).

More information on how to dynamically alter you query string is given here.

Yes, there is full support for SSL via the Java JSSE API which support SSL 3.0 and TLS 1.0. Configure any individual web page to use SSL by ticking the 'Secure (https)' check-box in the settings dialog for the relevant test case.

Configuring your client VM to accept the returned certificate is outlined in more detail below under the known bugs section.

Double click on a web page icon on the main screen to bring up the test case settings dialog. Double click on the web page of interest and select the 'Request Properties' tab and specify the alternate host with sub-domain below.

If authenticating against the proxy, click on the 'Authorization' button and enter your user name / password information in the form.

To include form based authentication into your test case, the easiest method is to add an initial 'login' page that represents the login form. This page must send over the username and password using standard naming conventions. The form action must be j_security_check. A typical URL for your form based authentication login page might be:

j_security_check?j_username=myusername&j_password=mypassword

where myusername and mypassword should be substituted with the username / password for login. Make sure the request method is POST.

Note, unless all connections are over SSL, all data is sent over as clear text. If SSL is used to encrypt the login information, select the 'Secure (https)' option in the page settings dialog.

You'll probably need to ensure that the login page occurs as the first page of your test case as, presumably, other requests will only result in a redirection to the login page if the user is not first logged in (handling login after redirection to a login page is more difficult and would require a response checker check each response and perform a login cycle if required).

More information about form based authentication in J2EE containers is provided here.

The throttle works to increase or decrease the 'pause time' between each web page download. Hence, varying the throttle as your test run proceeds allows you to control the rate at which requests are made to the server.

The throttle can be varied manually or programmatically. See the throttle help for more information on how to operate the throttle.

The throttle can be shown when viewing graphs of hit rate / download rate etc. This allows you to easily ascertain how you website / web application is responding to changes in the server load.

Information is made available by JBlitz in the following ways:

• The Statistics Manager allows you to export combined statistical information that summarizes the statistics collected for any given test run.
• The Graph windows allow you to export the displayed graph data. The graph data is controlled via a 'Legend' that allows you to pick and choose the test cases to view. You can also optionally include the throttle value in the exported data.
• The Graph window also allows you to export the data displayed in its own 'Legend' table via the right mouse button.
• Every table (e.g. Error Inspector and Response Recorder) has a right mouse option to export the data shown within the table. Either data for the selected rows or all rows combined can be exported.

In most instances, this fact is transparent to you. JBlitz behaves like a regular desktop application. In fact, being a Java application actually gives you an extra level of protection - everything JBlitz does is validated by the Java virtual machine at execution time.

On Windows, JBlitz comes with full install / uninstall support. A shortcut can be created during installation that will run JBlitz from your desktop or quick launch bar. An executable 'JBlitz Pro.exe' is created in your installation folder that will also run JBlitz.

On Unix and Linux, the JBlitz distributions come in either ZIP or TAR GZIP formats. These distributions contain the JBlitz JAR file and associated documentation. You'll need a 1.4 or higher Java virtual machine installed to run JBlitz. More information on how to install and run JBlitz for these platforms is given in the installation instructions.

Java gives JBlitz it's cross platform capabilities. The JBlitz JAR file containing the code is binary identical across all Java platforms and should run similarly on any platform that supports Java.

Yes, if you *really* want to. We do, however, recommend that you work with the system default look and feel that JBlitz uses as this is the one that looks best for each platform and the one that has been tested against the most.

To change the look and feel, you'll need to pass in a system property to JBlitz. This is most easily done by altering the command line to include the look and feel class name you want to use. For instance the parameter:

-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel

loads up the Metal look and feel. How you pass this parameter into JBlitz depends on whether you downloaded and ran the Windows installation program or are running the jblitz.jar file directly. In the former scenario, you need to edit the file JBlitz Pro.ini in the installation folder and add the parameter to the end of the line starting Virtual Machine Parameters. In the latter scenario, specify it on the command line after the 'java' part and alongside any memory options you may be specifying.

Other look and feel classes are held under the javax.swing.plaf package. Their availability depends on the platform you are running on. If you try to use a non-existent class, a load failure will occur when starting JBlitz.

A common issue with many variants of the Windows operating system is that there are strict limits applied to the number of concurrent network connections allowed on any given machine. With Windows XP Professional, for instance, the limit is 10.

There are, however, some remedial steps that can be taken to alleviate this problem. A full description of the issue and possible courses of action are outlined in the bug report below.

The specification of the client (testing) machine will depend highly on the level of load testing that is required. For normal testing of 10 to 15 pages by, say, 50 virtual users, a modest system with a 800MHZ CPU and maybe 256MB memory will suffice. For heavier loading than that, a higher spec system will ensure that your testing does not become constrained by the limitations of the testing machine itself.

Of course, a more thorough level of testing can often be achieved by purchasing a multiple installation license or a site license and running your test systems on more than one machine in parallel.

By default, if you downloaded and ran the Windows installation program, JBlitz will be configured to use up to 192 MB of memory. You can alter this amount by editing the file JBlitz Pro.ini in the installation folder and altering the line starting Virtual Machine Parameters (the part where it specifies -Xmx192m).

If you are working with jblitz.jar directly and running it from a command line or shell, then you may specify the memory usage using the VM parameters -Xmx and -Xmm to say (in MB) the maximum and minimum amount of memory to use.

Generally, JBlitz requires at least 64 MB of memory for normal use. JBlitz will need more memory if your are using a large number of virtual users, using very long URLs or if your website is returning very long response pages or headers.

Here are some tips that may help reduce the overall memory consumption when running JBlitz:

• Disable the Log Console. (main menu Tools -> Log Console...).
• In your logging settings ('Logs' tab), choose file based logging instead of in-memory logging. Disable logging entirely if you don't think you'll need it.
• In the Preferences dialog (main menu Options -> Preferences...), choose a lower number for the recording capacity of the Response Recorder and Error Inspector ('Recording and Logging' tab). This will minimize the number of records maintained in memory while your tests are running.
• Under the 'Dynamic Substitutions' tab disable the use of '%p' dynamic substitutions (assuming that you do not require them). Select the entry '%p1 ... %p9' in the left hand list and then ensure the check-box 'Enable use of %p substitutions' is unticked. This will save some memory that would otherwise be required to track the substitution history for each virtual user.
• Generally having as few extraneous windows open as possible will minimize the memory overhead. Use the main menu option Window->Close All Windows to close all ancillary windows.
• Try running JBlitz in console mode. This usually requires a lot less memory than the normal GUI mode. See the help file for usage of the '-console' command line parameter.

JBlitz 5.x has been developed and tested against the 1.4.2, 1.5.0 and 1.6.0 JVMs from Sun Microsystems. JBlitz requires the use of at least a 1.4 compatible JVM. This is because it uses many of the advanced APIs and features offered by the 1.4 JVM.

The use of another vendor's JVM is not necessarily precluded so long as it supports at least the same APIs and features as Sun's 1.4.2 JVM.