A Developer’s Life is Like a Box of Chocolates: You Never Know What Bug You’re Gonna Get – Part 1
Intro
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.
What happened
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.
Action plan to figure out 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.
Context: The stack on which the server-side application is based consists of Apache HTTP Server, PHP, MySQL and Less CSS. The interface navigation is handled through Javascript, as well as all the small animations and background calls.
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.
Process
Step 1: Break down the search field into macro areas
Possible causes…What are the main causes of a web interface slowdown?
- Server-side synchronous processing: for example, a PHP script that is not optimized and takes a long time to run.
- Too much data to trasfer (connection): excessive total resources (in terms of bytes) are requested, which take a long time to be transferred from the server to the client.
- Synchronous client-side processing: there is an unoptimized Javascript script that prevents the browser from loading the page quickly.
Step 2 NOT optimized: Figuring out whether to either exclude or to focus on everything that happens server-side
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.
Step 2, optimized version: Figure out directly what to focus on using the browser’s built-in analysis tools
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%.
Result: I immediately excluded everything that happens server-side + everything that has to do with connections and resource transfer from the set of possible causes. So from now on, total focus on javascript scripts (spoiler alert – that’s my second error, but we will go into that in the next post 😉 ).
These Solutions are Engineered by Humans
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.
Author
