Using nodejs
Primer
When a developer listens to the word performance the one thing that comes to the mind is the time taken for the process to operate on an input to produce output. There is nothing wrong with this definition and is the easiest way to get started if you are interested in being hired as performance engineer.
Now that we have settled the units of performance as time let us think about how we start. For any tuning of performance of an application irrespective of whether you are a performance engineer or a developer; you begin with benchmarking.
Benchmarking is the process determining or establishing a baseline for a metric relevant to performance of a process. The dry definition could also be rewritten for our context as –
Benchmarking is the process of determining the time taken for a standard compute process to complete.
Many programming languages flourish and the apple of many eyes is the programming language of javascript. We will be delving into the benchmarking approaches and tools available. Approaches and tips narrated in this dispatch will help you in the situations where you have to determine why a function or endpoint takes longer than typically expected to yield a result.
General practice
Many a time in one’s career we end up picking reign from another developer. While doing so almost always information on the current code is not available from the day one. Performance information is of relevance to this dispatch where the current benchmark in the production environment isn’t typically documented.
As a developer the first activity will be for you to define your own benchmarking environment typically in your own workstation. By defining the environment tasks like the current CPU speed, in GHz its clock speed in Hz, average CPU load in % with none of user apps running etc has be to be observed. Once the environment is baselined with a definition use one of the techniques described below to baseline the run time of a program / function / module in units of time.
This exercise will save you from energy draining discussions which (after you doing this exercise) are so subjective; to the likes of – “CR3987 has slowed down the application”. You having done the benchmarking can quickly return back the facts which are far objective; to the likes of –
“We inherited base code which consumes 2.9 sec in development mode for the hash computation. CR3987 has on average across CPU load factors yielding 2.87 sec in development mode for the same hash computation. There is pragmatically no performance impact due to CR3987. However, if you want, we can benchmark other aspects of application to detect a leak”.
Imagine if you did not had performed the benchmarking then your version might look like –
“No, we did not make any core changes in CR3987 which could slower the application. Let us discuss with the team which have reported the slowness”.
We let you determine which version is productive and leads to a solution.
Tips native to the nodejs
Javascript standard by themselves evolve using the tagline called ECMAScript. Without a bit of history connecting the two strings might be difficult. But for this context take them as given. Let us stack one more fact before we get to the topic of the section – nodejs itself uses the javascript. Title of this section could also be re-read as Tips native to javascript.
WebAPI’s performance class
WebAPI is a list of interfaces that can be used to develop web app or site. Though not necessarily these API’s are consumed with Javascript.
Performance API defines the performance interface that can be put to use for measuring client-side latency measurement within the web application. Beyond benchmarking the API can be used to calculate the frame rate of the animation on the client side. Do observe when we talk about the client-side measurement, we talk about diverse systems with different time settings. Performance API’s is aptly designed to consider monotonic clock instead of system’s clock. As well it does not use Date type. It uses DOMHighResTimeStamp for the date and time type.
Performance API defines the interface called Performance. This interface has methods named mark, and measure. These two in tandem and bunch of other methods help measure the performance of a function of interest.
So, you would have following script of sort to do this –
|
performance.mark(“InterestingFunctionStart”);
someInterestingFunction();
performance.mark(“InterestingFunctionEnd”);
performance.measure(“ComputeTime”, “InterestingFunctionStart”, “InterestingFunctionEnd”);
console.log(performance.getEntriesByType(“ComputeTime”));
performance.clearMarks();
performance.clearMeasure();
|
WHATWG community’s standard console
This is a group of people from various organizations (to begin with Apple, Mozilla, and Opera) who define and maintain the standard for the Web Hypertext Application Technology (ies) [Working Group] (WHATWG). Console is one such standard. This is a term which any javascript developer would have been familiar with right from day one when they write the Hello World program.
There are nifty methods to the likes of time, timeEnd and timeLogwhich helps us achieve similar results as with the Web API’s Performance interface.
You would use it some similar fashion as follows –
|
console.time(‘Interesting function);
someInterestingFunction();
console.timeEnd(‘Interesting function);
|
Do note here that the moment you call the method timeEnd the time consumed is printed in the diagnostics console. Needless to say, if you are running the browser it will be the developer toolbar’s console, for the nodjes it will be the console window.
Using the console API, you can print the time elapsed since the hour glass was turned. Method timeLog serves that purpose. You can have it called multiple times like below –
|
console.time(‘Interesting functions);
someInterestingFunction1();
console.timeLog(‘Interesting funcions’);
someInterestingFunction1();
console.timeEnd(‘Interesting functions);
|
Unlike the Performance API the string used for the different time methods should be same. Change of the string will cause the timer to yield wrong or incorrect results.
Libraries serving towards benchmarking
You have other options as well beyond you using the API’s in different standards. One thing to watch out for when you use these API’s are the browser compatibility. Fortunately, both the API’s are equally supported in nodejs. But they have evolved over different version. Do not forget to check the version when they were added to the nodejs.
Beyond this there is one more approach you can use – 3rd party library. These libraries can be consumed by importing them using the npm package manager.
Search in npm with the keyword: benchmark yields 375 packagesat different stages of lifecycle. The interesting one of them is the performance package. The interesting thing about this package it has its own library of standard compute functions which are of different level of space and time complexities. Thus, if you run benchmarking exercise, it gives a generic context for the environment’s performance.
There are more such interesting packages. Inspect them before putting them to use in wider context.
Parting thoughts
Performance and benchmarking of code is the process which indicates a developer has come to age where the code he produces is going to be consumed by other developers. This blog is a quick start for practicing performance telemetry in your application as you code. Cathedral of performance engineering is very big, intriguing and beautiful.
In case you thought about the http channel and over the network performance measurement, might be you are already doing it using the developer tools in the modern browsers. It is for another dispatch. Till then make your programs run like Flash!!
