Note: This is the first in a series of blog entries on Jazz Server performance.  Links to additional blog entries appear at the bottom of this blog.

I have spent the past couple of weeks doing some interesting investigation into some performance issues and some system tuning with one of our customers.  It has been a really interesting exercise for me, and like most of the times that I work on things like this, I have been learning a lot.  There are a lot of things that exist out there that can help you check the operational health of your Jazz infrastructure.  Some of these I knew about, some of these I didn’t know about, and some of these I knew about but had forgotten.  Now let’s look at some basic techniques that just about anyone can use to identify issues in their Jazz infrastructure, and improve performance.

No Software Needed – Using Metronome to Gauge Network Throughput and Latency

The Jazz architecture is based on a set of Jazz servers located in some central location, like a data center.  You communicate to these servers using either the RTC Eclipse Client, or through your web browser.  This communication occurs over your network, and the speed and throughput of your network has a direct impact on the performance of the Jazz tools.  Slow or low-bandwidth networks will make the use of ANY web based application slow and painful.

What it Does

There is a great little tool included with your RTC Eclipse client, called Metronome.  Now I know what you are going to say, “Our performance with the Eclipse client is fine, we just have some web client issues”.  Metronome can help with those as well!!  The tool does a repeated ping test to the Jazz server, which gives you a range of ping times and a more accurate indication of latency in your network.  Networks with high latency will demonstrate poor performance, with either the Web client or the Eclipse client.

The tool will also do an upload and subsequent download of a 2MB file to the RTC server.  This gives you an indication of the network bandwidth that you have available to you.  This is important, since you may have a fast network, or a network with large bandwidth, but if the network is fully loaded, the effective speed of your transactions will be slower.  So don’t be fooled by a gigabit backbone, or a muscular NIC card.  use Metronome to find out what your throughput REALLY is.

If your performance is poor in the Eclipse client, the tool provides a lot of information which you can use to help you determine where you might be experiencing issues.  Read more details about the Metronome tool, and some of the other information that it provides, in the Jazz.net article The Jazz metronome tool keeps us honest.

How to Get Your Data

Metronome comes packaged with your RTC Eclipse client in RTC 3.x.  Once you have the Eclipse client launched, connect to your RTC server.  Then from the menu bar select Window -> Preferences.  In the resulting dialog, navigate to Team -> Jazz Source Control, and check the box for the Metronome tool.

Now you will see a small metronome icon at the bottom of your Eclipse client.  

Double click on the icon, and select the connect that you want to test.  You will now see the Metronome results and guidance dialog.  Click on the Connection tab, and then click the Test Connection Speed button at the top of the dialog.  After the tests have run, you should then be able to see your results.  There is also some guidance on the types of results that you should expect to see.

What I See

I get pretty good performance with my laptop accessing the Jazz.net server.  When connected to my home network, with my cable modem, I get ping times in the range of 80ms – 120ms.  Anything below 200ms will give you acceptable travelling performance, and if you can stay below 100ms you should see acceptable performance.  Values greater than 200ms indicate that you will experience slower performance due to network latency issues.  Talk to you network administrator and try to get your client machine “closer” (from a network perspective) to the RTC server.

For the effective upload/download speed, I see for 10KB/s – 15KB/s for my upload speed, and a range of 80KB/s – 100KB/s for my download speed.  This seems consistent with what I see when I use either my Eclipse or Web client.  Downloading files is fairly responsive, but uploads of files (attachments, code, blog postings with lots of diagrams) can be a bit slow.  We like to see upload/download speeds in the 60KB/s range for what would be considered acceptable performance.  If you are not seeing this, you can either look to increase the effective network bandwidth, or move your Jazz infrastructure to a less “noisy” part of your network.  In my case, all I can do is curse my ISP, and broadband cable technology in general.

One thing to note is that your results will vary depending on when you run the tool.  If you see good performance in the early morning (when nobody is loading up the corporate network), but poor performance at lunchtime (as everyone in the office watches their favorite YouTube videos), run metronome at those times and note the differences in the values returned.  The key thing to remember is that while a single measurement will not prove or disprove adequate network performance, it can help you understand your actual network performance better.

Other Things to Try

You can also use the Netalyzer tool from Berkley labs.  This tool does an analysis of your network performance, and will give you an idea of what kind of performance you are seeing.  It is not just a simple dumb speed test (like Speedtest), or a simple ping measurement, it does a full assessment of the performance of your browser/network.  It is a web based tool that runs a Java applet within your browser.  It worked on Firefox for me, although my Chrome browser had some issues with it.  The output is great, and does a great job explaining everything.  Here is a look at what I saw when I ran it from my home office.

Interestingly enough, it pointed out that my ISP has a poorly performing DNS server, and over buffers packet traffic.  That refers to Buffer Bloat, a common issue today with network performance on the Internet.  I was impressed with the information provided by the tool – it took roughly 3 minutes to pull all of this together.

What Next?

This series of articles is continued.  Here is a list of the topics covered:

Advertisements