Both IE9 and Firefox are trying to pack a lot of information into a mixed text and graphical display. Not all of the information is likely to be useful in all situations.
I am still learning about the capability of these tools, so please accept my comments as coming as beginner with these tools whose comments are likely not as precise or accurate as I would like. I find these tools very similar in form and function. Once started, they both capture the details of the HTTP transactions that each browser logs. I found the Network tab had the most immediately interesting display for the JHS random delay problem. The F12 IE9 Network display confirmed that IE9 was seeing random delays in one part of the HTTP processing, the 'Response' part (see http://www.jsoftware.com/jwiki/DavidMitchell?action=AttachFile&do=get&target=IE9delay1.png for an example). It also confirmed that the delays were 'random', but not infrequent. The logging from JHS/jconsole showed that the IE9 transactions that had the 3 second (post change) delays correlated with logged JHS/jconsole socket RECV timeouts. I am not sure there is more information to be gained from the IE9 logging beyond confirming the IE9 delays and identifying how the delays fits in IE9's sequence of processing. I posted the the last two screen shots for two reasons. I found it interesting that IE9 and Firefox have what amounts to an identical tracing and debugging tool. Plus, I try to encourage the use of such tools to resolve this kind of problem. In my experience, it is all too easy to come to incorrect conclusions unless they are backed up by evidence. And I think that both of these tools can be helpful in providing evidence. The merged winsock and JHS/jconsole logging of the timeouts that I created seems to show that the JHS/jconsole RECV timeouts are typically preceded by a lack of recorded IE9 SEND socket logging just before the timeout. To me, this looks like it might be the typical communication sequencing issue: at some point, both sides of the conversation are waiting on the other. And then JHS/jconsole is the side that times out first and continues the conversation. I need to look at a winsock trace+JHS/jconsole log merger for a Firefox test to see if I can see any differences in the data flow besides IE9 missing SEND(S). Another step could be to put more logging into the javascript JHS code to see if the details of the missing SEND(S) can be pinned down further on the JHS/IE9 side. On 1/23/2012 9:57, Raul Miller wrote: > I think what's confusing me is that I do not know how to read the times. > > It looks like a set of events (arranged vertically) and I would > imagine that the timeline displays all fit into the same time interval > (that the left side is always "time 0" and the right side is "time > n"). So I would expect that the numbers displayed to the right of the > timeline to be either the duration from start to end or the duration > from time 0 to end. But when I look closer, neither of these can be > the case. > > For example, near the bottom of the display in "IE9delay3.png" are > four bars which extend all the way to the right. They have labels: > > 1.55s (a short lavender bar) > 656ms (a long lavender bar with a very small bit of yellow) > 1.83s (a long lavender bar with an even smaller bit of green) > 15ms (a long lavender bar with no variation that I can see) > > Immediately underneath is a very short (lavender) bar labeled 31ms. > > So, anyways, I cannot figure out what those numbers mean, and do not > understand the display. > > I also see a big yellow box that claims -43.094 seconds request time > since the beginning, with some details which account for approximately > 0.063 seconds of time. I also am confused by that. Does the negative > duration mean that the "beginning" has not happened yet? Does the 43 > seconds have any significance here? And so on... > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
