I ended up discovering a tool called The Grinder which uses Jython to build performance-testing scripts that you can then use to test your application. I even built a little framework in Jython to make the test scripts more modular and reusable. Over the next few days I'll be publishing three articles this one included that talk about Grinder.
In this article I'll go over installing and setting up Grinder. I am not going to go into too many details since my aim is to provide information that will enable you to have Grinder up and running quickly. If you want more information, you can look at the rather thorough Grinder User Guide. Note: The instructions in this guide relate to a Linux environment. You can run Grinder in Windows; the set-up is not much different.
The only differences will be in installation locations and shell scripts. If you want more information about setting up Grinder in a Windows environment, please take a look here.
Downloading everything you need. First you need to download Grinder. You can get it from here. You should only need to download the binary distribution and not the source distribution unless you're planning on extending Grinder. Unzip the installation file to somewhere convenient. I recommend chown 'ing the installation directory to yourusername:yourusername. Make sure that your version of the JDK is greater than or equal to 1.
The second thing you need to install is Jython. Note that this is not absolutely necessary, but I found it useful to have around when I was trying to parameterize the test-scripts, and I needed to test something out first.
I recommend not using the Jython that comes with Ubuntu. Instead, download and install Jython 2. For demonstration purposes, I'm going to show you how to set up Grinder with a local grinder.
To get an explanation as to what these terms mean, take a look at the picture below that I shamelessly stole from the Grinder documentation page:.
As you can see, you essentially have a console that sits on top of everything. It acts like a controller, pushing out scenarios and test cases scripts to agents that are running on load-injection machines.
Each agent is in charge of one or more workers that inject load into the system you are testing. The workers also report data back to the console. The console aggregates all the data it receives from the workers and presents it to you. This is the ideal scenario that you would use for actual performance testing, however like I said before, I'm not going to concentrate on that - I'm just going to show you how to quickly set up Grinder and run a performance test on your local machine.
If you want to look into distributing scenarios and tests across different agents, you can take a look here. The first thing you want to do is set up a grinder. I put this file into the root directory of the checked out app so basically, wherever you checked out your app. It's not necessary to put it there; you can put it wherever you want. So open up your favorite text editor, and create the following file:.
The reason I have the following value is to prevent an error Jython complains about caches from popping up when you start a test. Jython caches imports and so you need to let it know where it can store the imports. Though it's not strictly necessary, you do need it if you are performing wildcard imports like java. Here you set up the arguments that tells the agent where the console lives. You don't want the load-generator hammering away at the app one request after another with a uniform interval.
These properties are used to configure the behavior of Grinder with respect to logging grinder. If you want more information regarding the grinder. Alright, now that you have the grinder. Before you start performance testing, you need to have a test. Grinder test scripts are written in the Jython language. You can write your tests from scratch if you wish it can be useful if you're trying to test things like XML-RPC , but more often than not you will be using Grinder's proxy tool to record a usage scenario and generate a test script.
It sits between the browser and the server and records requests and responses that move between the browser and the server. By itself, it simply echoes whatever goes through it in that sense, it makes a pretty good debugging tool , but we want it to generate Jython test scripts. First, you need to start up TCP Proxy. Simply run startProxy. A little window will pop-up letting you know that the proxy is running.
There's a textbox in the window that lets you insert comments too. Once you the proxy is started up, you need to configure your browser to use the proxy at localhost Now access the app you want to test, in your browser.
Log in and do whatever it is you need to do search for a contact, add a contact, send and email, etc. In the scenario I created, I logged in, searched for contacts, added a new contact, searched for more contacts, and then logged out. Put in the URL to your server and Firefox should grab the certificate and add an exception. Also make sure that you have no plugins trying to phone home through the browser.
TCPProxy intercepts every communication that your browser makes so you don't want to pollute your results with irrelevant requests I think it's possible to filter the data using the domain name, but I haven't looked into how to do it yet.
There are a few tests where you would like to supply data for example, when adding a contact. In the context of performance-testing, this is called parameterizing. Since Grinder uses Jython, it's actually pretty easy to parameterize a test. I'm only going to reproduce parts of the script since the entire script itself is rather large however, if you want to look at the entire script, you can download it :.
Grinder import grinder from net. To use a proxy server, uncomment the next line and set the host and port. These definitions at the top level of the file are evaluated once, when the worker process is started. You can access the unadorned instance using request A method for each recorded page.
Replace each method with an instrumented version. You can call the unadorned method using self. From the above listing, you can get a general idea of the anatomy of a test script.
Of course, there's a little bit more that goes into this, so if you want a detailed description, take a look at this page in my next article, I'll go into more detail about the anatomy of a recorded script.
However, to make it exactly what we need, we need to parameterize certain areas. The first section we need to parameterize is where we add a new contact look at the page18 method. Right now, it inserts a contact called "Mikey Mike" with the email " [email protected] ". That's not particularly useful if we're running this test a bunch of times.
We want to parameterize this value. What we're going to do is create a random first name, last name, and email address, and use those values in the request. Here's how we do it once again, I'm only showing the pertinent sections of the code i. We need to import java.
Random for random number generation from java. As you can see, we've now parameterized the first name and last name values that go into processContact. There is still one more thing we need to parameterize. If you go back and take a look at grinder. This means that there are going to be 5 threads running. We don't want the same user logging in more than once our app doesn't allow it.
So what we also need to do is parameterize user logins:. Setting up an array of dictionaries i. To parameterize logins, I created an array of dictionaries that store username and password combinations. Then, based on the thread number which is zero-based and which I can access via grinder. Now we can actually start running the tests and recording data! The first thing you need to do is start up your app. Then, you need to start the Grinder console. Use the startConsole. After that, use startAgent.
You should see something like this in your shell:. You can check it by running The Grinder console. To do so, enter the following command in The Grinder directory:.
Creating a test To start with performance testing, we need to have a test. The Grinder comes with a TCP proxy tool. It is a proxy process that can be placed between a server and browser. It records the request and response between a server and browser, and sends the results to a terminal window.
I used Mozilla Firefox as a proxy server. Setting the proxy: To set the TCP proxy, follow these steps. Open the Firefox menu and click on the Options tab. In the Options window click on the Advanced icon. Select the Network tab. In the Connection section, click on the Settings button. Set the HTTP proxy to localhost and as the port.
After setting the proxy in the browser, start the TCP proxy. The output of the TCP proxy is shown in Figure 3. The console also displays a simple window that allows the TCP proxy to be stopped cleanly. This window allows the user to add comments to the script during recording. The application that you want to test in your browser can now be accessed.
I used a simple Web application for creating a new user. In the test scenario, I created a user, logged in, executed a simple SQL query and then logged out using my application. Note: While running the TCP proxy, make sure that no other tab has been opened. The TCP proxy intercepts every request that the browser makes.
I am showing only a part of the script because the whole script is very large. From the above code, we get a basic idea of the structure of a test script.
This script is 98 per cent useful. The script can be parametrised according to need. To log in with different names, I need to create an array that stores user names and password combinations. Then, based on The Grinder thread number, I try to log in with the appropriate user name and password. Running the test After you have recorded your script, you have two methods to replay it: 1. You can edit the grinder. You can use the console to send your script to an agent.
Each agent will need a grinder. Next, copy grinder1. Please see the code below:. The number of virtual users is: Number of worker threads x number of worker processes x number test machines. The console window opened is shown in Figure 6. Now, start an agent, open another terminal and enter the following command:. Sometimes, this command gives the error shown in Figure 7 if you have set the classpath temporarily.
The output of the above command is given in Figure 8. Now, distribute the file to the agent, and set the root directory for script distribution. If not, then right-click on grinder.
Run the test. Check the process and view results. Go to The Grinder console, click on the Process tab to see currently running processes. Go to the result and the Graph tab of The Grinder to see the result of testing. Analysing The Grinder data The Grinder is a tool that is made for developers. It generates raw data, which is not very user friendly. Once Grinder collects the data for you, you can do whatever you want to do with that data.
For a quick overview of your data, you can use a tool called GrinderAnalyzer. The Grinder is a pretty powerful and flexible performance testing tool. I hope that after this tutorial you will have the knowledge to install and set up The Grinder for testing your application. For more information, please refer to the Grinder documentation available on The Grinder website.
Can you provide me the solution. Save my name, email, and website in this browser for the next time I comment.
0コメント