Finally I get to the final chapter of my blog postings on Jazz Performance. I ended up doing parts 7, 6 & 5 in reverse order, because those seemed to be the most relevant at the time. So I guess that this makes this post the least relevant of all! It isn’t, but the area that this post covers tends to be a very focused one, and one that may not apply to many of our customers. This post focuses on the performance of the web client in your Jazz environment, and how you can tell where time is being spent in the responses to user requests through the web browser clients.
One of the key points to understand here is that when using a web browser, is that there are three distinct phases in any web client transaction with the Jazz application server. There is an initial request for data from the web browser to the Jazz application server. This is followed by a response, or responses, from the Jazz application server, which is returning the data requested. The final phase is the assimilation of the data returned to the browser, and the subsequent JavaScript processing to transform this data into meaningful information which can be displayed to the end user.
When we discuss web based performance issues, the typical complaint is with slow rendering of plans in the web client. This is because when returning data for plans (as well as some other types of user requests), a large amount of data needs to be returned from the Jazz application server. Data on each work item in the plan needs to be retrieved. Once the data has been returned, the JavaScript engine then needs to parse and present the data in a meaningful way to the end user. Finally we get to the actual presentation of the information back to the end user. In this blog article, we will look at how you can determine how much time is spent in each phase, and how you can do things that will impact this performance.
Using Web Browser Monitors
The best way to determine how time is being spent, is to use one of the web browser debugger and monitor tools that are commonly used. I will cover a tool called Http Watch. I start with Http Watch because it works for both Firefox and Internet Explorer. It runs on Windows, and is an add-on/plugin for both Internet Explorer and Firefox. Once you have it installed, go to the Tools menu of either browser to activate it.
Once you launch Http Watch, you will see a window at the bottom of your browser. This is where you will be able to see exactly what is going on in the browser. Now navigate out to Jazz.net, and check out one of the plans. Go out to Jazz.net and log in, using your user ID and password (because I know that you already have one). Now before you navigate to the plan, make sure to hit the record button in the Http Watch window, which tells Http Watch to begin recording and timing your browser interactions. Then navigate to the RTC Product Backlog Plan. It might be easier to navigate to the plan first, start recording with Http Watch, and then do a page refresh. Be careful though, because the browser cache may influence the actual load time in this case. Either way, you should see a graph begin populating in the lower window indicating what has happened during your display of this plan. Wait until the plan is fully displayed and rendered, then press the Stop button in the Http Watch window. Now you can go and look at the data.
Checking out The Data
As you can see in the diagram above, the results get shown in a graph, with the length of each line showing the relative length of time needed for each operation. You also can see the time stamp of when the operation occurred, how long it took, the type of operation (GET, POST, etc.) , the type of resource (CSS, json, JavaScript, images, etc.), and the address that the request went to or came from. The initial series of GET operations are pulling the typical header information and CSS information for rendering the page, along with the initial JavaScript needed for the page. The first POST command is to “https://jazz.net/jazz/service/com.ibm.team.apt.internal.service.rest.IPlanRestService/getItems2”, which is the beginning of the retrieval of the information for the plan being displayed. As you scroll down you can see the series of GETs and POSTs being made, and see the amount of data being transferred with each of these. Further down the trace you will see a large POST to “https://jazz.net/jazz/service/com.ibm.team.workitem.common.internal.rest.IWorkItemRestService/getWorkItems”, which has a large amount of data returned. This is the retrieval of the work item contents for the work items in the plan. After this point, there will be some traffic, but most of this time after this is spent in processing and rendering the data coming back from the Jazz application server.
What Does It Mean?
Keep an eye on how long it takes for the correct data to be identified on the Jazz application server, how long it takes to return that data, and then how long it takes to render the data. It will give you an idea of where the time in processing typical user requests is spent. is it waiting for data to come over the network? Is it waiting for Jazz application server responses? Is it in the JavaScript processing? This information will help you determine where you should focus your efforts, if you are debugging performance issues.
One of the things that I have used this for is to highlight the differences between the various browsers and browser versions that my customers have available to them. In many instances, customers are limited in what they can install on their machines, and they may be on earlier versions of some browsers. This allows them to compare browser performance in their environment. Not only are you able to compare the overall time needed to display page contents, you can also see how much time is being spent in processing and transferring the information, and contrast the differences between your browsers. It is something that I strongly suggest that you do, and let your users know what you have seen. End users want to know the differences in browser performance, and they also like to see benchmarks of what is considered “normal” performance in your environment. If they see that a particular plan takes 10 seconds to render for you, then they know to expect similar performance when they use the tools.
Setting expectations and getting performance baselines is important. Recording them somewhere visible to your users is even more important. If you begin getting complaints about slower performance three months from today, you will have a set of tools and measurements so you can objectively determine if things have deteriorated over time, or if the end users just have rising expectations. This objective data is critical when trying to address performance issues in your environment. It allows you to weed out the users complaining about normal performance, and allows you to quickly zero in on real problems. it will then allow you to measure the impact of any changes that you make to your configuration.
Other Things
I have only discussed Http Watch in this blog. Keep in mind that there are a lot of different tools out there that will do similar types of profiling. I know that a lot of our developers like to use Firebug for working with Firefox. Firebug is nice because it has debugging capabilities as well, which can sometimes come in handy. In addition, there is a built in capability in Firefox for doing a lot of this. Go to Tools -> Web Developer -> Developer Toolbar in your Firefox browser. This will launch some developer tools, like a debugger, that you can use to look into the JavaScript (if you care to). In Internet Explorer, you can use the F12 key to debug JavaScript in that browser as well.
Other Articles in the Series
This series of articles is completed. Here is a list of the topics covered:
- Jazz Performance Part 1 – Is my Network Causing me Pain?
- Jazz Performance Part 2 – Using the Admin Console
- Jazz Performance Part 3 – What does nmon have to do with my Jazz Server?
- Jazz performance Part 4 – Why WAIT, see what your Jazz server is doing
- Jazz Performance Part 6 – Obeying the Laws of Physics
- Jazz Performance Part 7 – What is JazzMon and Why Should I Care?
Dan Toczala's Blog 
Pingback: Tips and Tricks – How does Firefox Plugins help you as Jazz admin | Srikanth's Blog
Hi there it’s me, I am also visiting this site daily, this
website is in fact good and the viewers are really sharing pleasant
thoughts.