This post originally appeared on https://dynamicsnotes.com/retail-channel-performance-investigations/.
There may be a time during a Retail project when you likely will hear someone saying: “Doing X in POS is slow. What’s going on?”. If this is the case, my hope is that this during the implementation phase and not on a live production environment.
What do we do to find out what is wrong? Is it a customization to the CRT business logic, latency to an external call, generic latency to the server from POS, or a Microsoft bug?
The following steps will hopefully help to give an answer to these questions.
Latency between POS and RetailServer
RetailServer API timings as seen from POS
“Looking inside” RetailServer/CRT/SQL with Commerce Runtime Analyzer
Profiling Channel database SQL queries
Some things to remember:
RetailServer could be either Microsoft hosted or RSSU-hosted. It is agnostic to this investigation, but you need to make sure you are testing against the right RetailServer (especially if you use both Microsoft-hosted and RSSU-hosted at the same time).
Microsoft-hosted RetailServer in production cannot be accessed, so some of the steps below cannot be carried out on a production environment. It is advised to carry these out on a lower tier environment.
RSSU-hosted RetaiSserver, even in production, is under the management of the customer, so the steps below can be carried out, but with care.
Sometimes the slowness could occur only when there are multiple POS used at the same time. If that is the case, you can still use the steps below, but would have to reproduce the issue by running multiple POS.