I'm excited to formally announce that Database Performance Analyzer 9.2 is now Generally Available! 


This release of Database Performance Analyzer (DPA) has a very special feature only available when integrated with Server & Application Monitor (SAM) 6.2.1+.  We developed this feature based on the collective experience of DBAs and SysAdmins who've been caught up in nasty blame games.  Let me tell you a story...


blame-o-saurus-lg.jpgImagine a web site used by your customers that depends upon a database.  Not hard, right? Now imagine the customers have been calling in daily, about an intermittent performance issue that threatens your business.  It's been really irritating because the I.T. Pros just can't pinpoint the cause and it's stressing out executives who are demanding a swift resolution! 


  • The SysAdmins say that the web server looks fine.  No CPU spikes.  Plenty of memory.  No red flag in metrics. 
  • The DBA says the database server looks fine.  No CPU spikes.  Plenty of memory.  Very little storage IO and all queries received results within SLA.  There was a small spike of activity after the time the customers complained, but it was just a momentary spike in concurrent activity and again, all queries received responses within SLA.
  • The Web Developers want to blame the database because it's their primary dependency and it has caused them problems in the past.


So you've got 3 silos denying responsibility for the problem customers reported.  Executive attention focuses on the Developers who begin forming hypotheses they can't prove, like network performance is the issue or that web server and database server clocks may not have been synchronized and that little database spike actually did cause the web site performance problem.  And these are just the reasonable hypothesis.  Soon, you feel like you're on an episode of CSI, looking for a genius mastermind hacker that's broken into your system to steal customer data! 


This is a case where disparate monitoring solutions can leave you hanging... siloed... at each other's throats!  So what do you do?  Calm down!  First you need to clarify to everyone that they don't have a shred of evidence to prove any of these things.  But an integrated monitoring solution can give you a complete picture.  Let me show you how DPA 9.2 integrated with SAM 6.2.1 can help! 


chickenoregg.pngWith SAM 6.2.1, you can monitor an IIS web server with AppInsight for IIS which exposes some ASP.NET metrics that I love! :


  • Request Execution Time - Tells you how long it took IIS to complete the most recent web request.
  • Request Wait Time - Tells you how long IIS held a web request in a queue before it began processing it.
  • Requests Queued - Tells you how many web requests are in the queue because the web server has reached it's limit of worker threads.  Ideally, you keep this at zero!
  • Requests Rejected - Tells you how many web requests IIS has simply rejected because the queue is full.  GAME OVER!  YOU LOSE!


Now, when DPA 9.2 is integrated with SAM 6.2.1+, it adds a Query Response Time resource to your AppInsight for IIS view, which reveals how much *database wait time queries from the web server have incurred.  This enables you to perform a diagnosis of exclusion.  That is to say, if A and not B then C.  If (A) the web server requests are slow, you will see it in those ASP.NET metrics.  If the Query Response Time resource doesn't show (B) a matching spike in database wait time, then the web site performance issue must be caused by (C) something else.


So back to our story for a minute...  You see how the request execution time was high for a bit there, then suddenly dropped?  Do you see how the Query Response Time shows an inverse pattern?  The spike the DBAs mentioned that occurred after the web site problem...


Here's what REALLY happened...  True story from my past, actually.  It is true that historically, the database has caused many web site performance problems, but the Web Developers didn't evaluate every dependency.  As it turns out, the web server also relies upon 3rd party web services.  They've never been a problem before, so they haven't been monitored and were thus were overlooked.  Our web code needs these web services to complete before the web server will query the database and that is why we see the inverse relationship between Request Execution Time and Query Response Time.  When the 3rd party web services cleared their performance problem, the web server sent all the associated database queries to the database server, which responded to that load spectacularly, the DBA adds!


So as you can see, monitoring this web site with AppInsight for IIS and the dependent database with an integrated Database Performance Analyzer enables both teams to see the big picture in a single pane of glass.  Pretty cool, huh?


For more information about Database Performance Analyzer 9.2 features and value, check out the beta blog posts, my recent post on Geek Speak and a video explaining the difference between health and performance monitoring.


 


*database wait time - The amount of time a database client waited while the database server worked on the client's query.  Time is broken down into discreet steps performed by the database server, how long it spent on those steps.  Fpr more info see http://logicalread.solarwinds.com/response-time-analysis.