cbstats timing is misleading for DGM

Currently the CURD operation timing only time how long the whole operation took to complete when the item is in memory.

When the item is not in memory it will only time how long the front-end thread took to complete the operation and will not count for time spent in ep-engine.

I believe this is the workflow for not resident items:

1. Front end thread reads the operation of the network and starts the timer.
2. Front end thread asks the backend engine (ep-engine in this case) for the document
3. If ep-engine returns EWOULDBLOCK (i.e it has to get the item from disk) the front end thread will stop the timer and then move onto the next connection.
4. Once ep-engine gets the item it tells the front end thread that it is ready and the time starts again.

I believe this is working as design, however I do feel that it is misleading.

• Do we have timing stats for the total time an operation really took from being read of the network and being replied to? (Does mctiming have it)

• Should we change this design?