It is a constant requirement that systems retailers are directly interacting with should be Bigger, Better, Faster, Stronger (BBFS). In this blog post, I will dig into how the POS performance can be analyzed to better understand the transactional performance of the Dynamics 365 POS. What I’m specially interested in is how perceived performance is towards actual. What we think is good performance is relative to the observer. The average reaction time for humans is 250 ms to a visual stimulus, but newer studies shows that we can identify visual stimulus down to 13 ms. Your screen has a refresh rate of 17 ms. As time is relevant and the expected performance is close to real-time, this can sometimes lead to performance expectations that is actual irrelevant towards what is wanted to be achieved. We as humans cannot go beyond 250 ms visual response time, so this is important to keep in mind.
As you can see in the following video, 4 items is scanned and then a quick cash payment is done. The total time taken to complete this example transaction in CPOS is approx. 5 s.
But as you can see on the screen, there is a lot happening, and when the user interface is being redrawn. I wanted to go deeper to understand exactly what is happening when scanning. More specifically on what’s happening when adding the sales lines in the POS.
As the CPOS is a 100% web based application, we can use Google Chrome to take a deeper look into exactly what is happening. By pressing the F12(Or CTRL-Shift-I), you get up the developers tools.
Then start the recording (CTRL-E), add a line in POS, and stop the recording. Then you will see:
1. CPU load, Activity bars, Network calls
2. The actual animation on the POS display each millisecond
3. Exactly how long calls to the Retail Server is taking.
4. The entire REST-call stack being executed on the CPOS client.
Here you see an example where I added one line to the POS basket, and this resulted in 2 calls to the retail server.
If we look at one of the calls happening:
ScanResults() (*.dynamics.com/Commerce/ScanResults(‘07100’)?$expand=Customer&api-version=7.3) – This scans the product/item barcode and sends it to the retail server. In google development tool, we can analyze exactly what is taking place on this call. Here we see that the total time was 559.54 ms but the actual waiting time for the RSSU to respond is 263,69 ms(Waiting TTFB). The browser is waiting for the first byte of a response. TTFB stands for Time-To-First-Byte. This timing includes 1 round trip of latency and the time the server took to prepare the response.) I have measured the network latency to this Tier-2 with RCSU system to be 40 ms.
If I scan the item again, we see that the caching of DNS etc kick’s in the TTFB lowers to 132,80 ms.
As you can see you can really go deeeep, and analyze all what is happening, from client execution to server execution, without any debugging tools. Down to the milliseconds, and better understand the performance. The profile created can be exported and imported for deeper analysis. We can see that there are many factors that influence performance, from network delay’s to form refresh. Microsoft could have the pleasure of shaving milliseconds of the animations, server calls and J-scripts, but this is an ongoing investment from and R&D perspective.
My honest opinion is that the Cloud based Dynamics 365 for Retail POS is performing good. Network elements and the speed of light is a fundamental restriction. The use of animations also seams to affect how performance is perceived, but it does not affect the general performance and usability. Legacy system that is on-prem have the benefit of not having latency, but the cloud solution brings so many other positive elements. If you choose MPOS instead, these tools are not available and you can use fiddler for analysis. But a small tip is to have a CPOS client available when performance testing, as this also will affect MPOS.
Bigger, Better, Faster, Stronger !
But as you can see on the screen, there is a lot happening, and when the user interface is being redrawn. I wanted to go deeper to understand exactly what is happening when scanning. More specifically on what’s happening when adding the sales lines in the POS.
As the CPOS is a 100% web based application, we can use Google Chrome to take a deeper look into exactly what is happening. By pressing the F12(Or CTRL-Shift-I), you get up the developers tools.
Then start the recording (CTRL-E), add a line in POS, and stop the recording. Then you will see:
1. CPU load, Activity bars, Network calls
2. The actual animation on the POS display each millisecond
3. Exactly how long calls to the Retail Server is taking.
4. The entire REST-call stack being executed on the CPOS client.
Here you see an example where I added one line to the POS basket, and this resulted in 2 calls to the retail server.
If we look at one of the calls happening:
ScanResults() (*.dynamics.com/Commerce/ScanResults(‘07100’)?$expand=Customer&api-version=7.3) – This scans the product/item barcode and sends it to the retail server. In google development tool, we can analyze exactly what is taking place on this call. Here we see that the total time was 559.54 ms but the actual waiting time for the RSSU to respond is 263,69 ms(Waiting TTFB). The browser is waiting for the first byte of a response. TTFB stands for Time-To-First-Byte. This timing includes 1 round trip of latency and the time the server took to prepare the response.) I have measured the network latency to this Tier-2 with RCSU system to be 40 ms.
If I scan the item again, we see that the caching of DNS etc kick’s in the TTFB lowers to 132,80 ms.
As you can see you can really go deeeep, and analyze all what is happening, from client execution to server execution, without any debugging tools. Down to the milliseconds, and better understand the performance. The profile created can be exported and imported for deeper analysis. We can see that there are many factors that influence performance, from network delay’s to form refresh. Microsoft could have the pleasure of shaving milliseconds of the animations, server calls and J-scripts, but this is an ongoing investment from and R&D perspective.
My honest opinion is that the Cloud based Dynamics 365 for Retail POS is performing good. Network elements and the speed of light is a fundamental restriction. The use of animations also seams to affect how performance is perceived, but it does not affect the general performance and usability. Legacy system that is on-prem have the benefit of not having latency, but the cloud solution brings so many other positive elements. If you choose MPOS instead, these tools are not available and you can use fiddler for analysis. But a small tip is to have a CPOS client available when performance testing, as this also will affect MPOS.
Bigger, Better, Faster, Stronger !