Monitor Transactions and Locate Bottlenecks
By David Mack
If you ve ever tried to find a bottleneck in your code, chances are you wished for a tool like WebLens from Altiras. It allows you to monitor transactions and determine where the performance issues with your Web applications are located. WebLens will profile ASP.NET, P/Invoke, COM Interop, and Web services. And because most Web applications have a logical database layer associated with them, you can also profile SQL, Active Directory, and ODBC calls.
The installation isn t that difficult, basically giving you a choice of installing a server or client. The server-based software will reside on your Web site and collect statistics about your Web application. The client-based software will connect to the database used by the server software and retrieve and display the information the server has collected. The installation also includes a distribution of the .NET Framework, as well as MSDE. Although it does make for a longer download, it s nice because all the requisite software is there except the OS and IIS.
I had a small Web application that I thought had a minor performance issue. Two things immediately got my attention: I didn t have to register the Web application as WebLens automatically detected it, and I didn t have to change any code to get a profile of my code.
WebLens doesn t automatically profile every transaction; you have to right-click on the target application (see Figure 1) and a filter dialog box is displayed. You are given choices of how you want to monitor the target application. I could profile using only transactions within a class/namespace, an arbitrary number of transactions, or both. I could also simply let it profile the entire application. Obviously this would result in more information to weed through; but if it s necessary, you can do it. Once I set up my filter, I executed the code, then went back to the profiler to do some analysis.
WebLens showed the transactions that it captured, as well as the duration of the transactions. I clicked on the slowest transaction and took a look at it. Using a toolbar I was able to view a graphical representation of my transaction, showing me how long the presentation layer took to execute, as well as the Web service proxy, Web service, and database. Because it s a chronological graph, you can easily determine which part of the transaction is the bottleneck. If you continue to drill down into that transaction, you are given the same information in graphical form and text. A pie chart on the right has all the functions broken down by time-based expense. WebLens refers to this as the Duration Chart . On the left you have all the functions displayed in a list with their associated expense. From here you can continue to drill down into lower functions or decide if you ve found your culprit. In my particular case, I was repeatedly opening a database connection I didn t need. I would ve found this issue eventually, but it was definitely quicker with WebLens.
Figure 1: Right-click the target application to start a WebLens profile.
I wanted to verify that WebLens wasn t actually skewing the results of my target application, so I ran the same IIS code on two different machines: One with WebLens running and the other as a control. I saw very little difference in the execution times and I attributed that to minor differences in configuration of IIS. Once I determined it wasn t skewing, I pointed it toward a transaction and analyzed the results. It did slow it down, but not tremendously and that s the cost of profiling. I like the fact that my entire application isn t being hampered unnecessarily. If I configure it to capture 15 events, it captures up to that amount and then stops profiling, thus removing any drag on the application.
On a larger application I began to experiment with the transaction filter. Some of the features there included the ability to profile transactions based on a count, or based on time (x number of seconds). There are quite a few permutations WebLens allows you to create to pinpoint what you want to see. One capability I did use often was the ability to exclude certain transactions, which cut down on the information I had to process. Once I found some interesting points, I could export them to XML via the main menu.
One behavior I noticed was that if you have caching turned on in IIS, WebLens doesn t catch those transactions and, consequently, doesn t give you a profile. It s an easy workaround to disable the caching in a .aspx file, but be aware of that while you are using the tool. I also noticed that constructor calls had the standard notation of .ctor instead of the ClassName. Once again, this is not something major, it s just something to be aware of when reading your results.
WebLens is a good product that can immediately pay dividends. Ultimately, it will result in a better user experience. It s also worthwhile because of the time and frustration that can be saved by a developer; test teams should also consider using this product if they have certain performance requirements. It s impossible to eliminate all the bottlenecks in your code, but you should always try to minimize them and WebLens will help you do just that.
Web Site: http://www.altiris.com
David Mack is a senior software engineer for Northrop Grumman and an independent consultant. He has more than 12 years of experience in object-oriented programming. Reach him at mailto:[email protected].