Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

The Grinder: Load Testing for Everyone

The Grinder: Load Testing for Everyone

The Grinder is an easy-to-use Java-based load generation and performance measurement tool that adapts to a wide range of J2EE applications. If you have a J2EE performance measurement requirement, The Grinder will probably fit the bill.

Paco Gómez developed the original version of The Grinder for Professional Java 2 Enterprise Edition with BEA WebLogic Server (Wrox Press, 2000). I took ownership of the source code at the end of 2000 and began The Grinder 2 stream of development. The Grinder is freely available under a BSD-style license.

This article will introduce only the basic features of The Grinder. I encourage you to download the tool and try it out. The recently published J2EE Performance Testing by Peter Zadrozny, Ted Osborne, and me (Expert Press, 2002) contains much more information about The Grinder.

Where to Obtain The Grinder
You can download The Grinder distribution from The Grinder home page at http://grinder.sourceforge.net. The examples in this article were run using The Grinder 2.8.3.

There are some mailing lists that you can join to become a part of The Grinder community:

  • grinder-announce: Low-volume notifications of new releases
  • grinder-use: The place to ask for help
  • grinder-development: For those interested in developing The Grinder
So, What Is The Grinder?
In short, The Grinder is a framework for generating load by simulating client requests to your application, and for measuring how your application copes with that load.

Typically, you will have begged, bought, or borrowed a number of test-client machines with which to test your application. You can use The Grinder console to control many processes across your test-client machines, each running many threads of control. The Grinder is a pure Java application, so there's a wide variety of platforms that you can use.

Three types of processes make up The Grinder:

  • Agent processes: A single agent process runs on each test-client machine and is responsible for managing the worker processes on that machine.

  • Worker processes: Created by The Grinder agent processes, they are responsible for performing the tests.

  • The console: Coordinates the other processes and collates statistics.

    Each of these processes is a Java Virtual Machine (JVM) and can be run on any computer with a suitable version of Java installed.

    To run a given set of tests, an agent process is started on each test-client machine. This process is responsible for creating a number of worker processes. Each loads a plug-in component that determines the type of tests to run and then starts a number of worker threads. For example, with the provided HTTP plug-in each test corresponds to an HTTP request to a URL. Each of the worker threads uses the plug-in to execute tests.

    The grinder.properties file is a configuration file that is read by the agent and worker processes, and the plug-in. This file contains all the information necessary to run a particular set of tests, such as the number of worker processes, the number of worker threads, and the plug-in to use. For most plug-ins, the file also specifies the tests to run and can be thought of as the "test script." For example, when using the HTTP plug-in, the grinder.properties file contains the URL for each test.

    The agent process and the worker processes read their configuration from grinder.properties when they are started (see Figure 1). I usually put the grinder.properties file on a shared network drive so I don't have to copy it to each of the test-client machines.

    The net effect of this scheme is to allow the easy configuration of many separate client contexts, each of which will run the same set of tests against your server or servers. Each context simulates an active user session. The number of contexts is given by the following formula:

    (Number of agent processes) x (Number of worker processes)
    x (Number of worker threads)

    The Console
    The Grinder console (see Figure 2) provides an easy way to control multiple test-client machines, display test results, and control test runs.

    The console is used to coordinate the actions of the worker processes by sending them start, reset, and stop commands. IP multicast is used to broadcast the commands simultaneously to processes running on many machines. The worker processes send statistics reports to the console, which combines these reports to produce graphs and tables showing test activity. The results of a particular test run can be saved for further analysis.

    The console also calculates and displays derived statistics. A key derived statistic that the console can calculate, but the individual worker processes cannot, is a combined transactions per second (TPS) figure for all the worker processes. This is because a rate, such as TPS, can't be calculated without a shared notion of the beginning and the end of the timing period. The console performs the required timekeeping function.

    Getting Started
    Have I whetted your appetite? Let's try running The Grinder. In this example, we'll start both the console and an agent process on a single machine.

    Having expanded The Grinder distribution and set up your CLASSPATH appropriately (see the README file provided with The Grinder for details), you can start the console with the following command:

    $ java net.grinder.Console.

    The console window should appear. Now change to a directory to hold the output of the worker processes and create a grinder.properties file:

    grinder.processes=2
    grinder.threads=5

    grinder.plugin=net.grinder.plugin.http.HttpPlugin

    grinder.test0.parameter.url=\
    http://e-docs.bea.com/wlsdocs70/index.html
    grinder.test1.parameter.url=\
    http://e-docs.bea.com/wlsdocs70/images/bealogo.gif

    This particular file specifies that there will be two worker processes with five worker threads each, and that the HTTP plug-in will be used. It also defines two tests that involve accessing resources from the BEA e-docs site.

    Start the agent process in the same directory as the grinder.properties file :

    $ java net.grinder.Grinder

    The console display will update to show the two tests. To instruct the worker processes to start the test run, select Start processes from the Action menu. After a short delay, the console display will show graphs of the incoming reports.

    Individual graphs will show the TPS for each test, and a full graph will show the total TPS. Alongside each graph, the mean transaction time, mean transactions per second, peak transactions per second, number of transactions, and number of errors recorded for each test are shown. The colors of the individual test graphs vary from yellow to red to indicate the tests that have the longest mean transaction times. The more red a test graph is, the longer the transactions for that test are taking.

    Try selecting the Results tab to see the results in a tabular form. You can also select the Sample tab to show the sum of all reports received during the current console sample interval.

    Note: If this example doesn't work the first time, it's usually something straightforward. Have a look though the documentation that comes with The Grinder, and if that doesn't help you, e-mail [email protected].

    Recording Test Scripts
    It's quite feasible to have HTTP plug-in grinder.properties test scripts containing hundreds or thousands of individual tests. The Grinder lets you specify the timing of each test. Additionally, the HTTP plug-in provides support for setting cookies, authentication information, dynamically generated requests, HTTPS, and other HTTP features. All of these are configured using properties in the grinder.properties file.

    Writing such test scripts by hand quickly becomes impractical. The Grinder is shipped with a tool, the TCP Sniffer, that can automatically capture test-script entries corresponding to the HTTP requests a user makes using a browser, and generate corresponding test-script entries. The TCP Sniffer is configured to sit between the user's browser and the target server and capture all the requests the browser makes before proxying the requests on to the server. (Technically the TCP Sniffer is a proxy and not a sniffer at all, but it's very useful despite being misnamed!) The responses the TCP Sniffer receives from the server are returned to the browser.

    You can start the TCP Sniffer in a special mode in which it outputs a recording of the requests you make with the browser as a full grinder.properties test script. You can then take this test script and replay it using The Grinder.

    More Than HTTP
    While the HTTP plug-in is the most commonly used, The Grinder can also be used in contexts other than Web and Web-services testing. Two other example plug-ins are shipped with The Grinder, a JUnit plug-in that allows you to repeatedly exercise a JUnit test case using many threads, and a raw socket plug-in.

    It's also easy to write your own plug-in - you just provide a Java class that conforms to a simple interface. I often do this to test J2EE applications with EJB or a JMS interface.

    The Grinder is already a powerful tool, but it can be improved. One of the key limitations is that each worker process executes the tests in the test script sequentially, in a fixed order. The Grinder 3 will address this by allowing tests to be specified using a variety of scripting languages, including Visual Basic, Jython, and JavaScript. Test scripts will allow arbitrary branching and looping, perhaps using the scripting languages' support for random variables. That's if I can find the hacking time.

    Happy grinding!

    Acknowledgements
    I am grateful to Tony Davis and the Expert Press team for their permission to use material from J2EE Performance Testing. As well as full coverage of The Grinder, this book contains much practical information about J2EE performance and application benchmarking.

    I also wish to express gratitude to VA Software for the SourceForge site (http://sourceforge.net/). SourceForge is without doubt a great resource for the open source community and is responsible for the continued success of The Grinder and many other open-source projects.

  • Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...