Now that we have a set of metrics to use to validate the performance of our web application we can now start to dive deeply into resolving issues. The first step in this journey is actually a step often overlooked by those that I encounter. Professionally speaking 3 in 5 performance consultations that I am involved with are actually resolved by taking the points in this post into consideration. So let us get started looking at users & the environment.
Step One: Is This User Specific?
The first question that should be evaluated with any performance review is the less-than-optimal performance that you are experiencing linked to a specific user account. If the performance issue is related to a specific user it will be important to look quickly into this user's account and see how/why they are different than other users in the system. Do they have more data associated to their accounts than the rest of the users? Have they done something differently?
If not user-specific, is it tied to a specific user type or class? For example is the performance issue only experienced by users that are designated as site administrators, or only users with the "Members" role?
If you still haven't found any similarities, great, your issues might be easier to identify. But continue to step two! However, if either of the above tests resulted in situations that were either a user or user type-specific it is important to understand how this will impact your testing and optimization. First and foremost, dive into your application code a bit earlier in these situations as you might be able to identify things faster being familiar with the differences between users and or security roles. Additionally, it is imperative that PRIOR to making any changes for a user, or user type-specific issue that you identify performance testing & validation requirements not only for the affected users BUT additionally for the users that are not impacted.
This is a common error to be caught up in the issue that is affecting members, deploy a fix, and now all of a sudden two weeks later you are fixing an issue for all non-members. Then you find out that at the end of that issue was caused by your prior fix. Without proper testing and validation strategies, you can be caught chasing your tail more than you spend actually fixing the issue. Yes, this takes a bit more time upfront, BUT, it will pay off in the end.
Step Two: Is This Environmental?
This is an issue that is a bit harder to pin down, but equally as important. Is the issue identified as something isolated to a specific location, or piece of equipment? For example, if the site only slow when accessed from the home office, and fast for the rest of the world? Or does it only render slowly on those using iPhones?
Depending on what is identified as part of this analysis a few different options can be uncovered. If it is tracked to a single physical location the most probable cause is connectivity issues, and the final resolution will be outside of your web application. If the issue is specific to users on a particular browser it might be better to look at discrepancies between that browser and others that are performing well. Overall the key here is that if you have environment influences involved in the performance of your application most likely you will NOT be able to resolve this without outside impacts.
Next Steps
Now, at this point we have looked at the metrics we want to optimize for in part one. In this posting, we have looked the impacts of users & the environment. The next step in this process is to look at the client-side execution of our application. How can we optimize the client-side behavior of our applications to result in better overall performance?