Wednesday, 2 April 2014

Business/Application Transaction data (APM) (7 of 15 Data, data everywhere and not a bit to use)

As I said on Monday a good APM tool will give us a LOT of useful information about the workload in our environment. It’ll also present the data in a way that allows various teams to talk in the same language.  

So it will help define what a user transaction is, and where that transaction spends it’s time.

A user action = A transaction
     Log on, Search, Add to Basket, Checkout, Payment = 5 transactions

So what are the benefits, difficulties and issues to avoid when using APM? 

Benefits

     Common language
     Service based
     Defined SLAs
     Real workload volumes (Planning benefits)

Usual Difficulties

     No tool capturing this data (see my recommendation at the end of this blog)
     No access to the data held (Typically controlled by Operations)
     No import facility to capacity tool

Avoid
     Exporting data from both tools into Excel and manually cutting and pasting to get combined reports

This is data that is traditionally hard to get hold of.  Either it’s simply not collected, or it’s fragmented and hidden by teams who don’t want to lose control of “their toy”.  And quite often it’s not been designed with the intention of combining its data with something else, like a capacity tool.

If you get or have an APM tool running the last thing you want to do is spend time exporting everything into excel to combine the data.  (88% of spread sheets have errors). 

My recommendation, if you haven't got an APM tool currently, is to take a look at SharePath - it monitors in real time and provides you with the real user experience(not synthetic) http://www.metron-athene.com/products/sharepath/sharepath-technology-overview.html

On Friday I'll be discussing SANs, as this seems to be the weak point in the performance chain right now and where we can get that storage data from.

Phil Bell
Consultant


No comments:

Post a Comment