Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
The customer complained about poor response times in his web application. The application's architecture was similar to the Web Application Archetype. Notice Services Agent box that connects your application to downstream services? Our assumption was that the services agents are too chatty causing the performance hit. Netmon only made it clear.
We took captures on the application server where the Server Agents are to identify what other downstream servers are accessed. In no time we get very clear picture - the application server was accessing other three downstream resources:
There are two well known ports - 443 and 1433 - so we could safely assume there is communication over SSL/HTTPS and SQL Server. The other one - 1414 - turned out to be MQ.
Next step was to identify which one of the conversations is causing us troubles the most - either by chatty communication or by just long running transaction.
Looking at Time Delta column for HTTPS stateless communications we found nothing exciting regarding the latency:
For MQ communications we used magic ContainsBin(FrameData, 0,"StringToFindGoesHere") to identify XML messages going back and forth over MQ transport. For example, to find the beginning of the XML message we used the following filter:
Similar technique was used to correlate request and response XML messages.
To identify SQL communication we used shiny new TDS parser available for free download on Codeplex - SQL Parser in Latest CodePlex Package. I particularly like this one, it shows SQL Server communication without using SQL Server Profiler:
This post is made with PracticeThis.com plugin for Windows Live Writer
Alik, this is an excellent case study which documents not only fundamentals of analysis, diagnosis, & remediation, but also & perhaps more importantly that we oughtn't jump on the latest-&-greatest simply because either 1) marketeering hype &/or 2) that the latest-&-greatest often isn't actually the greatest.
Thanks for good words.
I am actually fine with 1) and 2). What bothers me the most is in many cases folks are just throwing tools/money/CPU/RAM on problems; it never helps in long run.
Look what a great quote I found here:
"Application performance is not an event or something you do once — it's a practice."
CEO, Precise Software Solutions Inc.