Good morning, Fellas!
Today, I will tell you why my last posting with the video of how to capture http traffic is so important.
You all probably know the symptoms - you run your Coach and it's loading. You check the news in a separate tab, you jump back to the Coach, still loading,
loading aaaaaaand loading. Okay, I am exaggerating a bit, but sometimes the loading times feel like they are taking forever.
Now, before contacting IBM Support to help you solving your performance issue, I wanted to share some steps you can use to further diagnose your problem.
And for that, we will need this *.HAR (HTTP Archive) file that is being generated.
Now, to look at this HAR file, you will require an HAR Viewer (http://www.softwareishard.com/blog/har-viewer/).
Now simply drag&drop your HAR file onto the page and click on the Preview tab.
Here you will see all the requests with request/response, as well as header information, the response codes to the requests and most importantly - the timings.
Since we have long loading times for our Coach, we are particularly interested in those loading times.
A good indicator is the bar on the right hand side. If it is purple and the number given next to it is quite small (it's the actual time this request took in milliseconds), that's good.
Just some general remarks:
The purple bar indicates the wait time, i.e. the time the client waited for a response from the server. The smaller, the better. Of course it depends on the size of the request, network latency, server load etc).
You may see a brownish bar that indicates Blocking time. This is the time the request spent waiting for a network connection.
Blue bars indicate the time the DNS lookup took, green is the time it took to create the actual TCP connection.
Red bars show the time spent on sending the HTTP request to the server, and as said earlier, purple is the waiting time for the response.
They grey bar stands for the time it took to receive and read the complete response from the server.
In some cases you might even see SSL timings, which show how long the handshake etc took.
A good sample can be found here.
Just open the twisties at the bottom named "Cuzillion" and you can review these timings.
Or you can reload this page, grap the HAR from your browser console and it might look something like this:
I had a patient the other day, whose HAR file showed something very interesting. The actual waiting times were pretty small, all only a couple of milliseconds. Yet he still told me his Coach was ailing. There were pages and pages of requests. I stopped counting after 200. The farther i scrolled down in the list, I noticed that the brown bar continuously increased.
Brown bar? Yes! Blocking time! What was that again?
Exactly! The time waiting for a connection. I am not a plumber, but this smelled like a clogged drain. To use the medical term - the patient was probably suffering of constipation.
I asked my patient to take the longest taking call (it was a REST call - I could see that from the request details) - and run it against the server from the REST-API tester while capturing the HTTP traffic again. In isolation, no other requests, just this one.
The result: It finished in no time. So we knew it was not the DB or Server that had a problem with that request. This supported the drain theory.
What can cause such a constipation are the connection- and thread-pool settings for your server. In other words: If you eat more than you can egest, at some point you will feel constipated.
I gave him the advice to increase the pool sizes in an iterative process, always monitoring the performance of his Coach while doing so.
And voilá - the clogged drain was free again.
And if none of this helps, take two of these and call me in the morning.
Your Dr. D