We are all familiar with the cycle. We arrive at work on Monday ready to face the week in front of us. Over the course of the next five days the drudgery of the grind and the pettiness of the problems that attack us on all fronts wear us down until by Friday we can barely put one finger in front of the other. We celebrate our freedom on the weekend with all manner of revelry. Then, rejuvenated, we enter Monday with a spring in our step only to find ourselves beaten down again.

Yes, we all know and live this pattern. But we don’t expect our computers to emulate it.

Yet that was the problem that Sergio faced.

He was staring at a PHP application whose performance curve seemed to defy our expectation of the regularity of computers. Sort of the opposite of Einstein’s version of insanity, this was doing the same thing over and over again and getting different results. Or at least the same results, but taking longer and longer to arrive at them.

The Web site had been in production for six months. And it worked. At least it worked based on the lack of bug reports from the users (which we all know is the gold standard of ‘working’). But while gathering some requirements for an upcoming enhancement, Sergio spent some time observing how the application was being used by, you know, real people.

When he watched the users on Monday there was nothing unusual to report. They went about their chores and the Web site responded to most actions within a second or two. However, by pure chance (or dumb luck), he happened to schedule one of his other observational sessions for a Friday and was puzzled by the results. The Web site’s response time has risen from barely noticeable to barely palatable. Instead of the second or two, the pages were taking between 20-30 seconds to render.

When he questioned the users, they just shrugged it off as ‘how the application worked’. Which, of course, was why it was never reported. Yeah, this is how the road to hell got paved.

But Sergio was not the type to be satisfied by waving it off. It just seemed ‘wrong’ to him. More like it gnawed at his insides like a spicy burrito. And that was enough to drive him to dig into the code.

After just a little bit of effort, he narrowed down the problem to the following method:

For the non-bilingual among you, getDateLundi is the French equivalent of getMondaysDate. Its purpose was to return the date for the Monday of the week that the $Date parameter was in.

Now PHP aficionados will quickly realize that the entire function could be replaced by “return strtotime('monday this week')”. But that’s not sufficient to fully appreciate the WTF-ness of the code. While ‘general’ is only a 1-row table, the getDateLundi method is called a number of times during the processing of a single record. As the list of records to display grows, getDateLundi is invoked a correspondingly greater number of times. So while there were only a few records to display (and therefore a few getDateLundis to call) at the beginning of the week, as you moved through the week, the number of queries would increase until, on Friday, the page would result in the method being called hundreds of times.

After the requisite facepalm, Sergio corrected the code and promoted the fix into production. The users were thrilled with the performance improvement. However, because no good deed goes unpunished, Sergio now frequently gets emails from the users, asking whether a particular behavior should be considered ‘normal’. So while the users are able to do their job faster, for Sergio not so much.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!