In this post I’d like to explain the technique I chose to discover the cause of a bug I recently worked on, and why I made certain choices, given the not-so-common circumstances: part of a GUI I was debugging stopped working. It depended on third-party code and was therefore largely unfamiliar to me.
Another peculiarity of this experience was that I had to juggle with some technologies that I haven’t mastered, for example stylesheets (LOL). So let’s look at some mistakes I made that caused me to waste a lot of time which I could have avoided.
Symptom: Severe slowdown when loading GUI pages, to the point of making it unusable.
That’s the summary of the message I received from the guys on the Service&Support team. To summarize: an application update, the triggering event. Unknown, sadly, the cause.
When dealing with a slowdown in an application’s GUI, the scope of research can get really broad. The stack of technologies and application layers that can contain the cause can be huge. If you need to debug the whole system step by step until you find the cause, you’d first have to be very very competent in each technology, and second, you should have a lot of free time available.
So, I decided to go for a search-by-exclusion technique.
For example, if the problem was a call to a webservice made from the PHP code, which for some reason went into timeout slowing down the whole script execution, I would have simply mocked up the webservice to see if that was the cause or not.
Possible causes…What are the main causes of a web interface slowdown?
Caught up in anxiety and eagerness to find the cause, I threw myself headlong into debugging the PHP scripts running on the server. So I configured my IDE (to integrate with PHP xDebug, to be precise) and put a breakpoint on the first piece of code that was executed solely by the guilty page. It made no sense to test the code that was also used by other pages which were not affected by the problem.
I went ahead monitoring the time very carefully between every instruction so I could catch every possible bottleneck. To my amazement – predictably – I reached the last line of code in the whole PHP script without noticing anything wrong.
Result: what happened server-side was not the cause.
Well yes, I made the biggest mistake, jumping in headlong assuming things that I shouldn’t have. Every modern browser – I used the by-far-most-used one in the world, don’t let me google that for you plz – comes with so-called developer tools. My dispassionate advice: don’t be like me, use them :). Specifically, there’s a section that allows you to analyze how resources are downloaded from the server to the client, and allows you to understand how the load time of the entire page is divided among the requested resources.
The load time of each individual resource can also be analyzed. In this case, I noticed right away that the resources were loading instantly. The browser received everything it needed to start rendering the page very quickly, which automatically removed the server-side and the connection problems from the search scope. In addition, the browser I used also provides a task manager (credits: @Thomas) which allows you to analyze what each open tab of the browser is doing.
More specifically it provides two key data points: how much CPU the tab is using and how much data it is exchanging with the server, both of them in real time. In my case while the GUI remained frozen with a blank page and the loading animation was still lighting up the tab’s title, no data was exchanged between client and server, but for some reason the CPU usage was 100%.
Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.