November 13, 2019
by Idan Mor, Deepa Iyengar
Technology companies often turn to third party solutions in order to improve performance and user experience, but dealing with a diverse customer base and serving multiple platforms, browsers, and devices is challenging. It involves understanding the limitations and capabilities of the users’ systems and the impact of the executed code on usability.
As a third party platform for online enterprises, Namogoo is responsible to ensure that its solutions do not interfere with the performance and customer journeys of our clients’ websites.
Achieving this requires being able to measure the capacity of the end user’s system to handle Namogoo’s code and then, to use this data to adapt the code so that the system’s resources can be better leveraged to optimize the user’s experience and minimize disruption. To do this, it is vital to understand how a system’s capabilities impact system time and how this is assessed by Namogoo’s platform.
What is system time?
Loosely defined as the time that a system spends processing data, system time as a measurement is also indicative of the speed of the system. It can be affected by a variety of factors such as browser, operating system, device, and network efficiencies.
Namogoo, in turn, could use this measured “weight” of the system to adapt its processes in implementing an efficient Customer Journey Hijacking prevention algorithm, customizing it to the efficiency of the user’s system.
Method 1: Measuring System capacity – Open Ended Timeframe
The simplest — or at least it would seem — and most intuitive way would be to execute a piece of code and measure the time taken to run it as in the example below:
There is an inherent issue with this method. The weight of this function can greatly vary between environments, therefore it’s not possible to rely on the system time that this method will calculate. As seen above, the number of loops is predefined, while the time measurement is open ended and based on the execution time. For example, running this method on a high-performing environment will produce a lower execution time, while environments with slower execution times would result in system delays and hence, produce a bottleneck.
Method 2: Measuring CPU/System Capacity Using Bound Timeframe
In contrast to method 1, the code here measures the number of loops being run within a predefined time frame. This addresses the main flaw in method 1, where the timeframe is unknown. The number of loops the system can run in the given timeframe is indicative of the performance of the system. Here’s an example of this method below:
To ensure that the start and end times are recorded at the very start of the millisecond, a while loop is introduced before the measurement loop, which assigns the time value right when it takes on the next millisecond value. This way, when the code enters the while loop for measurement, the time values are both at the start of the millisecond, making the calculation more accurate. Here’s an example of how this function is implemented:
This method can be run in parallel with method 2 to help maximize the accuracy of the system time measurement.