Case study:
We needed to test performance of various parts of our application. I wrote a metrics class containing all of the timing values we were intending to use, and stored that in the request. It worked OK, but was a very “brute force” approach, which I was not completely happy with.
public class Metrics implements Serializable
{
private long requestBegin; // where Spring interceptor first gets called
private long controllerBegin;
private long wurflBegin;
private long wurflEnd;
private long dataBegin;
private long dataEnd;
private long controllerEnd; // normally same as renderBegin
private long renderBegin;
private long renderEnd;
private long requestEnd;
}
Suddenly I realized there were sometimes two data query sections for some screens, eg. one to check the login details and another to query from the database. It was impossible to get the Metrics data structure to cover all cases. I didn't have a better answer, so I consulted with the team and my colleague had a smart idea:
“Create a StatsService that logged timing events for a conversation/request against ThreadLocal. Each timing event has a begin and an end, but the events are generic.”
Tip: If logic starts getting too complex or you find you have to do more and more workarounds to get the application to function the way you want, it's probably the wrong solution to the problem. Step back and consider if there is a better way. Discuss the approach with someone.
