Conventional passive methods measure the time between a user action that results in page loading (such as a click on a URL) and the onload event. In particular this is the case of any method where the script is injected automatically into the web site that is being monitored, as is done by APM tools. This approach is perfect for sites that have a classic kind of design. It is much less perfect when the dynamic aspect of the site calls upon asynchronous loading techniques. Thus, for an Ajax call, the time the request takes is not counted. And yet the time to access these data will affect the user’s experience.
RUM BI makes it possible to surpass such limitations by allowing the site designer to set his or her own timers. Then the times that are really important for improving service can be measured, drawing upon the analysis power of business intelligence tools.
A time can be started using this command:
Un chronomètre nommé Nom_de_l_univers est alors déclenché. Plusieurs chronomètres peuvent fonctionner indépendamment, en utilisant un nommage différent. Dans l’interface RUM BI, les données seront agrégées à l’intérieur de l’univers Nom_de_l_univers.
Pour arrêter le chronomètre Nom_de_l_univers, la commande suivante est employée :
Cet arrêt provoque l’envoi d’un ticket de mesure vers les collecteurs d’ip-label. Cette mesure sera agrégée dans l’univers portant le nom ‘Nom_de_l_univers’
Here is an example of implementation with a jQuery Ajax call:
clobs.startTimer(‘ajax_get’);//Les données sont prètes à être envoyées
url : “AJAX_POST_URL”,
data : formData,
success: function(data, textStatus, jqXHR)
//données – reponse du server
clobs.stopTimer(‘ajax_get’);//Le serveur a répondu, on arrête le chronomètre
error: function (jqXHR, textStatus, errorThrown)
The custom timers open up new monitoring possibilities. The impact of any remote object can be measured, even when it comes from outside sites, or how fast a “post” is. The waterfall chart below is one example. The conventional operation of passive monitoring would cause the timer to stop at the moment of the onload event, indicated by the vertical blue line. Immediately following this event, the measurement is sent to RUM BI (step 1).
Here RUM BI was configured to measure the speed of an additional action (a GET toward YouTube), which takes place after the onload (step 2). Following this event, an additional measurement ticket is issued (step 3).
Alexandre Bourret, Innovation Catalyst