Wait Statistics

Many relational systems provide information on wait statistics (or wait events depending on the platform).  As the name implies these are counters typically measured in milliseconds where the resource being waited on is logged in memory and can be queried through some kind of performance view or Dynamic Management Object.

With the paradigm shift of scopes and collections we are telling our prospects and customers that we can simply lift and shift their relational workload to Couchbase without having to do any heavy lifting. Whilst this is true there are a number of operational differences between relational systems and Couchbase when it comes to monitoring performance.

Wait statistics has become a very popular way of understanding where performance bottlenecks are and rightly or wrongly is taught as the  first approach by many consultants and training courses. Not having the ability to perform the same kind of performance assessment will cause a great deal of trial friction for those from a relational background.

The legacy relational market is huge and any inroad into bringing over similar functionality will help to reduce trial friction in this area. 

Wait statistics should be available as management views via the Query service as well as via the rest API. This would allow traditional DBA's to add value with little extra training as they will already be familiar with this tuning methodology and SQL language.

The following is the deck from a session around 7 years ago when I worked at SentryOne that introduces Wait Statistics to SQL Server professionals Wait Watchers; Gain SQL Performance Increases Fast! This deck will provide an example of how they work and how they can be used by an end user.

Currently SQL Server has over 1000 different wait statistics so it is possible to find very granular information on where bottlenecks lie without having to bring in Microsoft themselves to diagnose a performance issue.