Find answers to some of the most commonly asked questions about our solutions, from general information on licensing to more technical responses to installation, test case design and execution questions.
If you want to use the latest version of PureLoad and “Expire” date has past (check Help->License Key for details) you need a new license file.
Please contact firstname.lastname@example.org for more information.
Both PureTest and PureLoad are available as a download only.
Please go to page www.pureload.com/download to get the latest versions of our software.
There are no shipping costs or other hidden costs.
All prices listed are subject to the applicable sales tax/VAT, if any. The applicable taxes depend on the customer´s country of residence.
The software license certificate is sent by email to the address provided by you within 48 hours after payment has been received (normally much faster). The license certificate email includes information about your licensing terms and the license key file(s). If ordering a single license then the license key file will be attached to the license certificate email as pureload.license.
If you haven´t received your license file, please contact email@example.com.
PureTest and PureLoad online sales are processed by our partner cleverbridge. All major credit cards are accepted as well as payment via bank transfer, check or in cash. The ordering phase is processed via encryption and safe secure transmission of all data you enter. For inquiries regarding orders registered with cleverbridge, please check the cleverbridge contact information web page.
An evaluation license is designed for a 10-day trial of the software. You can only use the software for testing purposes during your trial.
This is mostly depending on the particular user definition of the system to be tested. Other factors are which hardware is being used to generate load and how CPU/network intensive the performed operations are.
The PureLoad license limits the number of virtual clients (worker threads). Each client can be used freely to simulate user behaviour. As a rule of thumb, one can generally simulate one user with one virtual client or worker thread. Read more about this in Best Practices, Worker Threads.
Sometimes but not always. It might be in this way but it does not have to be so. Threads have no context connected to them, they are a pure force. The only thing a thread do is to fetch a scenario and execute it. When the thread has executed one scenario it will fetch the next scenario and execute. If you are building your scenarios from an end user perspective then 1 VC = 1 thread. There is some more info on Best Practices, Worker Threads.
This depends on the platform as well as which version of Java VM being used. For most cases it should be technically possible to use at least around 2000 threads per worker. Also see Tuning PureLoad and the documentation Best Practices, Worker Threads.
Yes. Read more about this in the documentation, Best Practices, PureLoad and Firewalls.
Todays powerful hardware is well suited for hosting a virtualised environment.
Using standard server hardware you can run a number of OSs/workers in a virtualised environment. PureLoad Load Servers have been set up in a number of different virtualisation environments like OpenStack, VMWare and KVM.
PureLoad fully supports Basic and Digest Access Authentication. For NTML only limited support is provided (NTLMv1).
To load your custom tasks you first need to choose the tab ”Task Types”.
The tab ”Task Types” is located towards the bottom together with the tabs for ”Scenario Editor” and ”Parameter Generators”.
Then choose ”Task –> Load All Custom Tasks”.
It is possible to set up so that the processes are started automatically at re-start of your hardware but PureLoad does not provide any boot script for this. The processes are started manually with the start scripts that are available in <PURELOAD_HOME>/bin.
Running more than one worker on a single host is not recommended in general.
Each worker uses a base amount of memory just by starting. It is usually best to run one worker for each host and tune up the memory for the worker instead. When you reach the number of threads the OS can handle in one process, then you need to scale up with additional workers. Up to 2000 threads is usually OK, but the limit varies depending on OS and Java version.
The license is a text file that must be installed in the
The license in managed by the Naming Server so the license file should be installed on the server where the Naming Server is executed.
The IP-address specified in the license file must match the IP-address of where the Naming server is executed.
If you get error messages when starting PureLoad servers saying something similar to:
Error starting NamingServer at: host[192.168.10.1]:1099 Exception message is: Port already in use: 1099; ....
This means that the specified port is used by another process. The most common reason is that you already have an instance of the PureLoad server running. Another reason could be that the specified port is used by another program installed on the machine. In this case you must choose another port for the actual process. Read about System Properties in the documentation for more information.
If you see errors similar to:
Starting Installer ...
Could not display the GUI. This application needs access to an X Server
First make sure that you use Java 7 from Oracle:
# export JAVA_HOME=/usr/java/jdk1.7.0_79
# sh ./pureload_unix_5_2_3b3.sh
If you still have problems, please contact firstname.lastname@example.org.
Yes, in most cases it is possible to convert Jmeter, Tsung, or Silk test cases so that they can be run in PureLoad. Contact email@example.com if you need support or help to do this.
A PLC file normally represents a test suite. The reporting is per scenario which is typically used to represent a test case. So if you have a PLC file (test.plc) with 2 scenarios (Example 1 and 2), the JUnit XML report will look something like:
<testsuites> <testsuite errors="0" failures="0" hostname="mymac" id="1" name="test" tests="2" time="6.26" timestamp="2013-12-16T09:58:45"> <properties> ... </properties> <testcase classname="test.Example 1" name="Example 1" time="1.639"/> <testcase classname="test.Example 2" name="Example 2" time="4.621"/> <system-out> ... </system-out> </testsuite> </testsuites>
Add the following lines to your /bin/puretest.vmoptions:
You can then attach a remote debugger on port 5005.
The DB driver jar should be put in <PURELOAD_HOME>/extensions
With ”Max Connections” you can set how many connections that should be used within a scenario when going to different hosts. Using the default (1) means that when changing from one host to another, the current connection will be closed and a new connection will be established for the new host. If you use a number higher than 1, the specified max number of connections will be established and kept open.
In the HttpInitTask the default content type saved is text/. If your returned content is of another type this has to be specified. For example Save Content Types: text/, image/ will save content of types text and image. Using Save Content Types: text/, application/json will save content types starting with "text/" and "application/json". Content types are specified as MIME media types.
The ScriptTask uses BeanShell which is a scripted Java dialect:
Many things can be done using scripts, but they will use more system resources. When doing load tests it is good to try and minimize the usage of scripts.
Stop On Error: This means that the execution of the scenario or task sequence stops if an error occurs. This is typically to limit the number of error following the original error, or to avoid continue the scenario/tasksequence with possible corrupt data.
Timeout Is Error: This is to place the timeouts on the error statistics or in the time-out statistics.
TheHttpCloseTask is generally only needed when you wish to explicitly close the HTTP connection(s) in the middle of a scenario.
When a scenario finishes, it will automatically close all HTTP connections.
The Timeout variable is used to set the valid timeout value for each Task. The value -1 means that the task will never timeout. When a Task passes the timeout value an error will be reported.
This depends on the Java version used. For latest Java 8 version see:
The absolutely most common reason is that the server application does not respond. Try specifying a timeout for the tasks and see if the test continues (with a timeout being reported).
Check the response times for you operation in the Timeslot-graph. In the Timeslot-graph you most likely will find some transactions that takes long time (in the seconds range). You might also have some transactions that have a long timeout and are therefore occupying the worker threads for other requests.
If "Out of memory" exceptions appear in the worker log then you will need to increase the memory size of the worker JVM. To do this, modify the worker.args property in the
pureload.properties file found in the bin directory. For example to increase the max heap size to 3 GB, change this as follows:
Note: Always keep the -Xss setting as is.
If you run out of memory in the Console or the Naming, Taskspace or Manager server you must increase the heap size, defined in a file named program.vmoptions, where program is the program. You find these files in the bin directory. For example to increase the max heap size for the console to 2 GB, change the
console.vmoptions as follows:
This exception may also be caused by running out of other OS resources, for example max. number of open file descriptors on UNIX (see Tuning PureLoad, File Descriptors on a UNIX box).
Large scenarios that are executed many times (iterations) might cause the console to report out of memory problems. This is typically related to when the Update Interval setting in Tool Properties is set to low (polling to often). Increase the number of seconds and try again.
Also see the documentaion, Best Practices, Long/Large Test Execution.
If tasks fails with exception similar to:
java.net.BindException: Address already in use: connect
this means that you are out of TCP/IP connections on our worker machine(s).
See Tuning PureLoad, Network Connections for more information.
All values are calculated per timeslot.
The timeslot length is determined by the "Worker Poll Interval" in the Tool Properties.
So with a poll interval of 20 seconds, each slot will be 20 seconds long. During this time period, many results may have been processed by each worker thread.
With Y-Axis 1 set to "Min" this will plot the minimum value of all results measured during each 20 second slot. The same goes for "Max" and "Average".
TTFB is measured as the duration from making an HTTP(S) request to the first byte of the page being received. This time is made up of the socket connection time (if no previous connection), the time taken to send the HTTP request, and the time taken to get the first byte of the page.
Three measurements are presented. The minimum time to first byte (Min TTFB), the average time to first byte (Average TTFB), and maximum time to first byte (Max TTFB).
For the Time Slot and Time Slot Graph presentation the minimum, maximum and average is calculated for each slot. So if a poll interval of 10 seconds is used the minimum, maximum and average values will be calculated from within each individual interval.
For the Summary Graph the minimum, maximum and average TTFB is given as the result over the whole test. Here the minimum will be the minimum value ever measured during the whole test (among all values in all time slots), and maximum will be maximum value ever measured during the whole test.
Note that values for a sequence, or for All Tasks, is not the sum of the children (included tasks or sequences). They are the minimum / maximum TTFB of one particular execution of the sequence.
You can increase change load during execution by going into "Edit->ReplaceScenario Parameters"
See also our documentation.
We are sorry to say that you have encountered an error in the PureLoad software.
For us to give you the best and fastest support we would be happy if you can save a stacktrace for the error. To do this, please enable
pureload.properties for the worker manager.
This is disabled by default (to save memory on the workers).
Now run the test case again, and then send the worker logs to firstname.lastname@example.org
When contacting PureLoad support for help with problems related to test execution you can help speeding up the trouble shooting process by sending us the Comparer Data and your tests that are saved in the .plc file. The Comparer Data can be saved after test execution by going into "File - Export Comparer Data".
In Tool Properties you can choose two Distribution Policies, to follow "Exact Iterations" or to "Follow Distribution" where the Exact Iterations is used by default.
Let's say that you want to execute 100 scenarios per second.
If execution for a while goes below 100 scenarios/sec (say 80 due to high response times and not enough threads) for a while. If you select "Exact iterations" taskspace will try to adjust to a higher intensity when response times again lowers (go above 100) to execute the numbers of iterations specified before start of test.
If you select "Follow distribution" taskspace will try to adjust the intensity as close to 100 scenarios/sec as possible. But it will never try to "catch up" and exceed 100 even if it's been below this for a while.
This can be seen in the Result->Summary Tab by selecting the worker in the left menu. Note that this is tasks/s since beginning, e.g not per time slot.
Yes, PureLoad use a full-stack simulation of the client and this lead to that significantly higher CPU is required for the encryption of HTTPS.
A general recommendation is not to have a CPU and memory usage above 70-80%.
Failed or timed out tasks are not included in the min/max/average response time calculations.
From innovation, to validation and smooth operation, our solutions help operators and equipment vendors deliver outstanding services and performance to their customers.
Send us an email: email@example.com