Features of The Grinder 3
Thanks to Edwin DeSouza for his help in
compiling this feature list.
Last updated: 4 October 2011
Capabilities of The Grinder
||Load Testing determines if an application can support a
specified load (for example, 500 concurrent users) with
specified response times. Load Testing is used to create
||Capacity Testing determines the maximum load that an
application can sustain before system failure.
||Functional Testing proves the correct behaviour of an
||Stress Testing is load testing over an extended period of
time. Stress Testing determines if an application can meet
specified goals for stability and reliability, under a
specified load, for a specified time period.
|100% Pure Java
||The Grinder works on any hardware platform and any
operating system that supports J2SE 1.4 and above.
||The Grinder can simulate web browsers and other devices
that use HTTP, and HTTPS.
||The Grinder can be used to test Web Service interfaces
using protocols such as SOAP and XML-RPC.
||The Grinder can be used to test databases using JDBC.
||The Grinder can be used to test RPC and MOM based systems
using protocols such as IIOP, RMI/IIOP, RMI/JRMP, and
|Other Internet protocols
||The Grinder can be used to test systems that utilise other
protocols such as POP3, SMTP, FTP, and LDAP.
The Grinder Architecture
||Minimize system resource requirements while maximizing the
number of test contexts ("virtual users").
||Each test context runs in its own thread. The threads can
be split over many processes depending on the requirements of
the test and the capabilities of the load injection
||The Grinder makes it easy to coordinate and monitor the
activity of processes across a network of many load injection
machines from a central console.
||The Grinder typically can support several hundred HTTP
test contexts per load injection machine. (The number varies
depending on the type of test client). More load injection
machines can be added to generate bigger loads.
||100% Java Swing user interface.
||Worker processes can be started, stopped and reset from
one central console.
||Dynamic display of current worker processes and
|Internationalised and Localised
||English, French, Spanish, and German translations are
supplied. Users can add their own translations.
||Central editing and management of test scripts.
Statistics, Reports, Charts
||Pre-defined charts for response time, test throughput.
Display the number of invocations, test result (pass/fail),
average, minimum and maximum values for response time and
tests per second for each test.
||Collates data from worker processes. Data can be saved for
import into a spreadsheet or other analysis tool.
||The Grinder records statistics about the number of times
each test has been called and the response times achieved. Any
part of the test script can be marked as a test.
||Scripts can declare their own statistics and report
against them. The values will appear in the console and the
data logs. Composite statistics can be specified as
expressions involving other statistics.
|Record real users
||Scripts can be created by recording actions of a real user
using the TCP Proxy. The script can then be customised by
|Powerful scripting in Python
||Simple to use but powerful, fully object-oriented
||Arbitrary looping and branching allows the simulation of
multiple scenarios. Simple scenarios can be composed into more
complex scenarios. For example, you might allocate 10% of test
contexts to a login scenario, 70% to searching, 10% to
browsing, and 10% to buying; or you might have different
workloads for specific times of a day.
|Access to any Java API
||Test scripts can directly access any Java API.
|Parameterization of input data
||Input data (e.g. URL parameters, form fields) can be
dynamically generated. The source of the data can be anything
including flat files, random generation, a database, or
previously captured output.
||Scripts have full access to test results. In the future,
The Grinder will include support for enhanced parsing of
common results such as HTML pages.
The Grinder Plug-ins
||The Grinder has special support for HTTP that
automatically handles cookie and connection management for
||Users can write their own plug-ins to a documented
interface; although this is rarely necessary due to the
powerful scripting facilities.
|HTTP 1.0, HTTP 1.1
||Support for both HTTP 1.0 and HTTP 1.1 is provided.
||The Grinder supports HTTP over SSL.
||Full support for Cookies is provided.
||The Grinder supports multi-part forms.
||Low bandwidth client connections can be simulated.
||A TCP proxy utility is supplied that can be used to
intercept system interaction at the protocol level. It is
useful for recording scripts and as a debugging tool.
||The TCP proxy can be configured as an HTTP/HTTPS proxy for
easy integration with web browsers.
||The TCP proxy can simulate SSL sessions.
||The TCP proxy has a pluggable filter architecture. Users
can write their own filters.