Java profiling on OSX

Not so long ago I needed to profile a small application to check why a simple WebDAV listing call using Slide took 20 seconds. It turned out to be a network IO problem caused by a blocking readline call on the response stream. I usually tend to use JProfiler for finding out these kind of things, because it is very good at what it does. But because it is a paying application and my company doesn't provide me with a license, I have to keep my eyes open for alternatives (you can't keep working with trial licenses and Mailinator addresses aren't allowed when registering).

So when the Eclipse Test & Performance Tools Platform Project, TPTP in short, appeared on my radar thanks to DZone I decided to try it out. Since I'm using Eclipse as my primary Java IDE this profiling plugin seemed a perfect fit, but little did I know. In Eclipse I opened Help > Install New Software... and added the http://eclipse.org/tptp/updates/ URL as a new software site to download TPTP. After downloading, agreeing to some licenses and an Eclipse restart I was ready to use my newly acquired profiler, or ... maybe not.

I was getting all kinds of different errors, but mostly NullPointerExceptions and some Incompatible Platform messages. After some looking around it was StackOverflow to the rescue: even though TPTP is already at version 4.3 there still isn't a TPTP Agent Controller for OSX. You've gotta be kidding me! How is it possible that they leave such a large group of Java developers, the ones that use OSX, out in the cold. It gets even better, you can't even open the TPTP 4.3 release notes page in Safari without getting a Javascript pop with the message: Sorry but this page isn't currently viewable in Safari. WTF!

So my little excursion away from JProfiler came to a screeching halt and I had to return to my tried and trusted JProfiler once again. One day I'll have to convince the big cheeses to get me a license.

Update 9 september 2009: it looks like I'm not the only one complaining: Green's Opinion

Load testing gotcha nr. 1: logging

This will be a first in, hopefully, a series of short but important things to keep in mind when load testing. So without further ado:

Load Testing Gotcha nr. 1

Logging is a good thing, but too much will kill you, your performance and ultimately your server. So use it wisely young Padawan.

Logging and certainly good contextual logging is always nice when things go wrong, but during load testing it should be turned off or as low as possible. The reasoning behind this is that logging, certainly on the more verbose levels will impose a hard to ignore load on your CPU/Memory and certainly on your disk(s).

This extra load will influence the request/response times of your tests. So when your log level is set too high and doesn't reflect your production settings, your load tests won't be representative and can't be reliably used too predict production server behavior under load.

As far as I can tell there are only two reasons to load test using a more verbose log level:

1. You're actually suspecting your logging of being a performance bottleneck and as such you want to do some load tests at different verbosity levels to study the impact of your logging.
2. Your application is failing at certain load levels and you need more detailed logging to home in on the cause of the failure.

So this is my (current) view on logging and load testing. I also think that this view isn't only applicable on load testing alone, but should also be kept in the back of your mind during application development. What I want to say with this is that you always have to think carefully about what to log on which logging level.

And one extra free piece of advice: never, ever, use XML as a logging format. I have encountered it once or twice in the wild as a consultant and it will use about 30% more disk space than non-XML logging (possibly even more depending on the length of your tags) and isn't exactly human-readable unless you're name is Neo and you're living in the Matrix.

Another easy WebDAV test server

In the previous week I discovered another easy way to set up a WebDAV test server: Atlassian Confluence. This is a pretty neat wiki product that also exposes its contents via WebDAV. The Devoxx guys even used it to make their whole website.

To set up a new Confluence server you first have to download one of the fully functional 30-day trial editions here. After downloading you just unpack the file to reveal a standalone Tomcat server and then you'll need follow the installation instructions. In short this means:

• checking your Java installation: version and home directory
• setting a confluence.home value in /confluence/WEB-INF/classes/confluence-init.properties to a valid path somewhere on your disk
• make sure you don't have port conflicts
• start Confluence by starting the standalone Tomcat instance from the bin directory: ./catalina.sh start
• browse to http://localhost:8080
• follow the setup wizard you're presented with and remember the username and password you enter
  

After this you'll have a WebDAV server listening at http://localhost:8080/plugins/servlet/confluence/default. You'll have to authenticate using basic authentication with the credentials you entered in the setup wizard. By default there won't be much data available, but this can be easily solved by creating some spaces in Confluence and adding some pages to the spaces.