JMeter 2.4 Patched Source

If you are using a newer version of JMeter than 2.4 (the latest, as of the time of writing this), directions follow for which files probably need to be updated. If you’ve never built JMeter or a Java application from source, you are also in luck, as all the gory details are here, too!

Updating the necessary files

In the code above, I’ve only changed a couple of small things, based on this useful post.

1. Tell the listeners about the new port

   In src/core/org/apache/jmeter/engine/ConvertListeners.java, we need to let the listener know to respond on a given port. We use the JMeterUtils.getPropDefault method to get the port from the configuration, so we need to tell the code to use the JMeterUtils library. Go to the list of import statements at the top, and add this one to the list:

   
import org.apache.jmeter.util.JMeterUtils


   Then we just need to add the port as an argument to the Listener that’s created. Replace this:

   
RemoteSampleListener rtl = new RemoteSampleListenerImpl(item);

   with this:
   
int callbackPort = JMeterUtils.getPropDefault("client.rmi.callbackport", 0);
RemoteSampleListener rtl = new RemoteSampleListenerImpl(callbackPort, item);


2. Change the Listener implementation to take the new port

   Now, all we have to do is update RemoteSampleListenerImpl to accept the new port. In src/core/org/apache/jmeter/samplers/RemoteSampleListenerImpl.java, find the RemoteSampleListenerImpl definition and replace:

   
public RemoteSampleListenerImpl(Object listener) throws RemoteException {
super();

   with:
   
public RemoteSampleListenerImpl(int port, Object listener) throws RemoteException {
super(port);


Once both of those are complete, you’re ready to compile! Once you have the finished product, you can specify the custom listening port with the brand new, super shiny client.rmi.callbackport option in jmeter.properties file (it’s not in there by default, so you’ll have to add it by hand) or from the command line:


jmeter -Jclient.rmi.callbackport=12345


Building JMeter from source

If you’re from the non-Java world, building JMeter may seem a bit weird. It’s not just as simple as the traditional apt-get or configure/make/make install. You’ll be doing all of the building with ant, with a heavy dose of manual labor along the way.

First thing first – you’re gonna need to install ant if it’s missing. If you’re using a Fedora/Red Hat/CentOS box (including Amazon Linux!) you can do:

yum install ant


You’ll also need some additional libraries for that, to add support for ReplaceRegExp:

yum install ant-apache-oro.noarch


We’re going to assume you have java jvm and hopefully the java development kit installed, otherwise go hunt down the latest version from the internet – use yum or go digging here.

Now, by default, you should just be able to go into the base directory for the package and run ant install, but for me, a bunch of things failed immediately. Here’s what I had to fix:

xstream 1.3.1 has wrong source location

I don’t know why it was released with a broken dependency location (and no forwarding), but I finally found xstream at nexus.codehaus.org

in build.properties replace

xstream.loc = http://repository.codehaus.org/com/thoughtworks/xstream/xstream/1.3.1

with

xstream.loc = https://nexus.codehaus.org/content/repositories/releases/com/thoughtworks/xstream/xstream/1.3.1


Missing dependencies

I also found that you have to manually tell ant to go get any missing packages, which you do with this command:

ant download_jars


Can’t find javac

While building, ant died because it couldn’t find a suitable compiler. “But javac is installed!”, I said. I had to check where java thought it’s home was:


echo $JAVA_HOME
> /usr/lib/jvm/jre


Well, that’s not right!


locate javac
> /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/


Ah ha! We’ll just re-set the environment variable! We use the directory above the bin/.


export JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64/


Can’t find junit

Next, ant determined that it needed junit for unit testing and it wasn’t installed. This wasn’t handled by the previous download_jars installation, for reasons I don’t completely understand.


BUILD FAILED
/home/ec2-user/jakarta-jmeter-2.4/build.xml:911: Problem creating jar: /home/ec2-user/jakarta-jmeter-2.4/lib/junit/test.jar (No such file or directory) (and the archive is probably corrupt but I could not delete it)


So we go looking for where to get junit:


yum provides junit
> junit-3.8.2-6.5.3.amzn1.noarch : Java regression test package


It looks like amazon has built their own, but your system may tell you something different. We can still do:

yum install junit


Still can’t build (can’t create junit dir?)

Oh for eff’s sake. ant can’t even create the necessary directory for the junit tests.


mkdir ./lib/junit


Once all of that was done, I could finally run the command:

ant install


And all was well. Once you’ve had a successful build, you’ll need to chmod your newly-created binaries so that they can actually be run:


chmod a+x ./bin/jmeter
chmod a+x ./bin/jmeter-server


And then you should be ready to go! run ./bin/jmeter and the GUI should popup, letting you know that all is well!

The vast majority of JMeter’s configuration is done through a single file, the jmeter.properties file (which lives inside of the JMeter bin/ directory). Any of the properties in this file can be overridden by options on the command line – but since this is Java we’re talking about, the method is ridiculous (code for Linux/Mac):


jmeter -Jpropertyname1=value1 -Jpropertyname1=value1


Of course, that doesn’t work for every option. For instance, to tell the server that you want it to listen for the initial request on a port that’s not random, you have to do so as an environment variable set on the same line before you make the call to the server. Truly and utterly bizarre:


SERVER_PORT=1660 jmeter-server


As noted below, the server_port only sets the port used for the initial request from the client to the server to begin testing, the response from the server to the client will be sent on a totally random port. I also found that the setting above did not work for setting the listening port at all!

Server (Slave) Configuration

The server configuration is ridiculously easy. The server just does what it’s told, so you only have to tell it what port to listen on. In the jmeter.properties file, you only need to set the server.rmi.localport value to whatever port you want. (You can also set this from the command line using -J, see the example above.) Note that you MUST set this option to keep the server from listening on a random port! The jquery “default” is 1099.

Also note that if you’re having trouble with the Client not being able to talk to the Server, you need to restart the Client after you’ve made any changes to the Server. This is very counter-intuitive!

Now, you may encounter a case where the server is trying to respond to the client (master) but looking up the wrong IP address for the hostname. The fix is easy, simply add a record in your hosts file (often /etc/hosts) for the correct address.

Last, you should be aware that the server responds to the client’s request on a different port than the server_port specified – it will return test results on a random high-numbered port (45000-70000?). If you haven’t opened up your firewall to account for this, it may cause the server to throw a nasty connection error. Note that there is no way to set the response port by default in JMeter. However, if you feel like getting your hands dirty, you can hack the source to add this option

Client (Master) Configuration

The client configuration is only a little more difficult. You’ll need to set the server_port to the same value you used for the server, again in the jmeter.properties file. You’ll also need to set the remote_hosts – this should be a comma-separated list of all of the servers’ hostnames or IP addresses. For example:


remote_hosts=ec2-50-17-92-85.compute-1.amazonaws.com,ec2-50-17-94-90.compute-1.amazonaws.com


That’s it! Once you’ve got that all setup, you should be able to start jmeter and have the list of servers appear under the Run > Remote Start menu. Note that this does not start up the servers – you’ll still need to start them manually on each machine – it merely runs the current test on the already-running servers. You can also use Run > Remote Start All to run the current test on all servers at once.

As a final note, you might need to take a look at jmeter.log, also under the JMeter bin/ directory to debug anything that’s not working correctly. There are often a few useful messages in there to help you along the way.

The first thing to understand is that there are two main to go about using Jmeter. By default, Jmeter runs as a free-standing (GUI) application on which you run Tests directly from the machine it’s running on. You do this with the Run > Start option.

You can also, however set it up to run on other machines, reporting the results back to the original GUI. In JMeter terms, the Master from which you send the tests is called the Client, and the Slaves that run the tests are the Hosts. You have to configure which hosts to run on – afterward you can use Run > Remote Start > slave address to run the test on a single machine, or Run > Remote Start All to run on all slaves.

To get started, try running JMeter on your local machine, and writing a basic test. If you’re working locally, just running the bin/jmeter (or bin/jmeter.sh on Mac, bin/jmeter.bat on Windows) script should start up a java session and run the program on your machine. If you’re working remotely, Jmeter runs in an X-Windows environment – so if you’re on a Mac you’ll need to have X11 installed and running.

Writing Tests

There’s actually very good documentation on setting up a test by recording your actions clicking through a site, but here’s the short version. To create a new test, you really only need a few elements.

Note: adding elements (Nodes) to a test is tricky because the elements are all context-sensitive. If you haven’t selected the right parent in the list, you won’t be able to add certain children. I’ve listed the correct element to click on as the parent below.

• A Thread Group. Used to set the number of virtual users (Threads) and number of Loops (iterations, obv) for *each* slave to perform (if you’re using the local machine) Click on the Test Plan and then chose Add > Threads (Users) > Thread Group from the Edit menu or the right-click contextual menu. For the trial run, you might just give it 1 User, 1 for Ramp Up Period and 1 Loop
• A Listener of some type. This is the what shows you the results of the test, either by a chart, table, or other medium. The simplest one is probably the Summary Report – to add it, click on the Thread Group and choose Add > Listener > Summary Report from the menu. No additional configuration is necessary for this type of Listener.
• A Sampler – an actual test element. For instance, if you want to just grab one page off of a site to see if it’s working, you’ll add an HTTP Request Sampler. Click on the Thread Group again, then choose Add > Sampler > HTTP Request. We’ll want to test with a site we know is working first, so enter google.com for the Server Name or IP.

Once all that is entered, you can choose to Start your test locally through the Run > Start option. If you have not saved your test, JMeter will prompt you to do so. After that, if you click on the Summary Report you should see that there has been 1 Sample, with (hopefully) an Error % of 0. If you’re getting an Error % greater than 0, you should probably check that you’re properly connected to the internet and you’ve followed all the steps correctly.

Now that they system is working, you can try entering your own domain in, and maybe enter a Path of a particular page that you want to test. Note: be very careful when testing against your live site. Increasing your thread or loops too high can cause the server to stop responding. (Which is what we want to test in the first place!) It’s best to perform your load testing against a non-production machine. Like, say, one set up on Amazon AWS.

From here, this would be a good time to read that above article on setting up a test by recording your actions with a proxy server, to create more complicated an thorough tests.

When coding your own brilliant application, there are a few simple things you can do to avoid potential collisions and headaches later, especially if anyone else will be using your code.  Here are a few areas to pay attention to.

Namespace

First and foremost, you need to watch out for collisions. If you’re not using a language with built-in namespacing (e.g. PHP <5.3), you’ll need to manage this manually. Some areas that you need to watch out for are:

• Class Names
• Session Variables
• Local Variables
• Constants & Globals
• Database Tables

Most databases already have a “users” table somewhere, and an app of any size is likely to have a variable named “args” or “params” (or two, or ten…). For most cases, it’s usually enough to prefix your names with your application name.  Keeping your names verbose helps, too.

Program Flow

When writing code, it’s always a good idea to keep everything to small, reusable functions.  This is especially true of published apps, because your users are very likely to be using your code in ways that your original app is not.  Try to break things down to the smallest possible chunks, even if it looks pedantic in your application.  For instance, break up your createUser() function into separate functions to add the user to the user table, subscribing the user to an email list, adding the user to the default group, etc.

Assume that your code will be executing inside of someone else’s code.  Try not to use print and echo statements when you can simply pass returned values – only print as the final step.  (An easy way to fake this is to use output buffering.)  You never know where your output is going anyway – so don’t assume that it will be a particular format – it may end up as HTML, an email body, or in the error log depending on how it’s implemented.

Pay special attention to any implicit defaults or rules that your code expects.  Don’t force the code to expect complicated series of objects or parameters that any one else wouldn’t immediately understand.  Don’t rely on database restrictions to impose your business rules.

Assume that your code will be glued into an existing user system at some point – make your user system as user-friendly as possible.  Create big wide hooks that anyone can use later to interact with your user system.  Actually, do this for everything.  (Ok, WordPress, you got that one right at least.)

Keep things wrapped up in nice containers.  Don’t just leave large procedural chunks lying around for others to trip over.  Don’t forget to give some attention to your configuration files on this front.

Don’t use globals.  Don’t use globals.  For the love of God, don’t use globals.  I don’t care how clever you think you are (I’m looking at you, WordPress), you’re going to screw everyone else up if you use globals.

Don’t Step On Toes

When you’re managing your resources, it’s a good idea to be courteous of others.  If you’re using a database connection or local file, keep a copy of the handle around instead of relying on the implicit “last opened” scheme many languages offer.  And since you’re all such brilliant developers, I don’t have to remind you to make sure to clean up after yourself – closing any connections that you opened, deleting any temporary files you’ve created, and cleaning up any objects you’re done using.  Even better, write error handling into all of your code so these things are done automatically even if something fails!

One particularly abused area is Session/Cookie management.  I cannot begin to list the number of applications that hijack the session and fill/clear it wantonly.  In general, you should never be destroying a session, or blanking out the entire cookie.  Always sandbox off your content into a hash (using namespaces again), so that you can remove only the content you added.  Also, don’t ever set the session name directly – just use the default.  (At least, in PHP you can’t use two different sessions simultaneously – setting the session name removes the ability to use any other session).

In conclusion…

Do be a considerate programmer.  Do keep good fences (as they make for good neighbors).  Don’t build giant monoliths (as they attract groups of violent monkeys).  Stick to these rules and you’ll save everyone a lot of trouble in the long run.

The solution, though a bit of a hack, is to write styles for the div container that use the !important rule, which will override any inline styles. Here’s what the fix should look like:


#my_auto_complete {
position: relative !important;
top: -10px !important;
left: 0px !important;
}


Effectively, you create your a background image the maximum width that you expect the box to be, as you would do with sliding doors. However, instead of cutting off the left side (or right side, as you prefer), you keep the image intact. Instead, you simply align the image to the left on the outside and the right on the inside, leaving enough padding for the image edges to show through.

Here’s an example of the technique in action.
Update: Example now works in FF3, FF3.5, IE7, IE8 and Safari 3 and 4!

The only caveat here is that this won’t work for images with transparency, and only saves you one download (ostensibly). This technique could be expanded, however, to have the hover states of the button in the image as well (as in the sprites technique), or for all four pieces of the image, used in rounded corners and custom border styles. I wouldn’t recommend either of those for particularly large boxes, though, as you’d need a really large image for those, which doesn’t optimize well.


symfony doctrine:migrate --env=staging frontend 119


where “staging” is whatever the environment is you want to use (to match the name in the database.yml file).


$myobj = new Doctrine::getTable('MyObj')->find($request->getParameter('my_id'));
$myobj->property = 'New Value';
$myobj->save();


This is really straightforward, but if you don’t include the find() inline with the getTable() call, you’ll get an obscure “Unknown method saveTableProxy” error, which there seems to be no documentation for anywhere on the internet. It only took a couple of hours of trial and error to get this figured out.

In general, I’d still recommend Doctrine as an ORM, but the lack of consistent and clear documentation, with dreadfully obscure object methods, make for a very steep learning curve.

When using trigger_error(), you can use the expectError() as follows:

$this->expectError( $errorMessageToExpect, 'My message about this test case' );
my_code_that_causes_an_error();


Note that there is an internal queue of errors in SimpleTest, so it will expect precisely one error for each call to expectError().

If, however, you’re using throw you use expectException instead:

$this->expectException( $exceptionclass, 'My message about this test case' );
my_code_that_throws_an_exception_of_type_exceptionclass();


You can specify the class of exception to expect in the first parameter – the usual type would be Exception, of course. If you set the first parameter to false, it defaults to this type.