Monitoring response times for web applications is one way to enforce SLA’s (Service Level Agreements). Typically you define different SLA’s for different pages of your application. Why that? Well – because certain features of the web application might be more critical than others and therefore you want to ensure that the critical pages respond fast enough to satisfy the end user expectations.

User based service levels

Depending on the type of application you have you may have the need to enforce different SLA’s for different users or different groups of users. Why that? In case your application provides different member ship levels you want to make sure that the more the users pay the more satisfied they are with the applications end user experience and performance.

In order to do that it is no longer sufficient to enforce SLA’s on URL’s or Pages. You need to assign individual web requests to the actual authenticated user and monitor the response times per user name. Having the contextual information about the user or group for individual transactions/web requests enables you to enforce user based service levels.

With dynaTrace we get a PurePath for every single transaction that gets executed. The PurePath not only contains execution times, SQL Statements and log messages – it also contains additional context information like HTTP parameters and method arguments. There are easy ways to capture the user name for  Java or .NET based Web Applications. You can for instance capture it from the session context or from an argument value that is passed to the method that is doing the user authentication. As a sample I implemented an ASP.NET HttpHandler that is taking the authenticated user name and puts it into the Web Request Context which will then be captured by dynaTrace. With this information I can monitor individual users and their response times. The following illustration shows the response times split up by individual users using Business Transactions.

Response times by individual Users
Response times by individual Users

I can now go ahead and define SLAs for each individual user or even for groups of users.

User Activity Monitoring

As a nice side effect I can also monitor the activity of individual users by looking at the request count instead of respone time.

Activity by User
Activity by User

The above image shows that testuser5 has the most requests amoung the non anonymous browser. With a single click I can now drill down to analyze the actual URLs that have been requested by a single user identifying the slowest or most often requested pages.

WebRequests for the most active user
WebRequests for the most active user

The option to also analyze the individual page requests of a particular user now also allows us to set SLA’s for the combination of User and Web Page.

Conclusion

There are more options than just enforcing SLA’s on individual pages or URLs. It can be done on a much more granular level like User, Group or even the combination of User and Web Page. This enables you to keep your most critical users happy by reacting on performance issues that are experienced by them.