The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Performance difference between client GlideRecord and GlideAjax: Negligible

treycarroll
Giga Guru

I was part of a discussion about this this topic. The thread participants decided that GlideAjax should be favored over client-side GlideRecord, based on recommendations on the SN wiki.     I decided to see for myself.

 

I created a GlideAjax script to fetch a manager:

 

function onLoad() {
       var ga = new GlideAjax("GMF_BenchmarkSample");
       ga.addParam("sysparm_name", 'getManagerId');       
       ga.addParam("sysparm_userId", g_form.getValue('caller_id'));       
       ga.getXML(callBack);
}

function callBack(response){
       var answer = response.responseXML.documentElement.getAttribute("answer");
       alert(answer);
}

 

On the back end I used this script include:

 

var GMF_BenchmarkSample = Class.create();
GMF_BenchmarkSample.prototype = Object.extendsObject(AbstractAjaxProcessor, {
       
       //Log the error using server side error logging
       getManagerId: function () {
               var userId = this.getParameter('sysparm_userId');
               var gr = new GlideRecord('sys_user');
               if(gr.get(userId)){ return gr.manager;}
                       return null;
       },
       
});

 

Then I created a GlideRecord version to do the same thing:

 

function onLoad() {
       var rec = new GlideRecord('sys_user');
       rec.addQuery('sys_id', g_form.getValue('caller_id'));       
       rec.query(recResponse); 
}

function recResponse(rec) {
       while (rec.next()) {                 
               alert(rec.manager);               
       }
}

 

 

Based on the advice on the wiki, the GlideRecord version should perform worse ostensibly due to having to load all of the properties on the user record.       However I found this:

GlideAjax vs client GlideRecord performance.png

Since the client GlideRecord is considerably easier to work with and only causes a negligible performance hit, I'm switching to using it in the future.

 

(The test was executed multiple times, each time against the same INC record, with a margin of error of about 6ms.   Occasionally the GlideRecord script even outperformed the GlideAjax script.     The outliers happened when the wait time became 4-5 time longer than normal at random intervals.)

9 REPLIES 9

Sure, anything involving multiple lookups would be well suited for a GlideAjax call, but simple requests could easily be handled by an async GlideRecord.



Case in point, the 2 out of box Client Scripts on the Incident table, "(BP) Set Location to User" and "Highlight VIP Caller".   They use getReference with a callback, which is pretty much the same thing as an async GlideRecord.   I don't like the fact they use 2 different lookups to get the info, but that's a completely different conversation - A Better "Best Practice" Client Script


Kalaiarasan Pus
Giga Sage

This has been our favorite topic in.our organization for the last one year. You are just seeing one side of the coin. Do a test for some complex query and post your result. There glide Ajax will.be the clear winner.   Also glide records has some issue where there is a conflicting ACL on.the table.


felixs
Tera Expert

Hello,



ServiceNow Jr Developer here, just wanted to ask what you used in order to test the actual performance of the calls in the bottom part of your post. I am in the   middle of trying to convince my team that System Properties is the way to go for scripting, but am being countered with the gs.getProperty() call will be too expensive (resource/time) and will affect performance in a workflow or a scenario that has to work with thousands of records. I think this is a good point, but Im doing more research, as from a programming perspective, I think System Properties are the way to go.



Any info/input/direction you can provide will be appreciated, thanks!


I would definitely go with a System Property - not a good idea to use hard-coded values.   The data is cached, so the difference should be negligible and far outweighed by the flexibility you get with a property.   A lot easier to update one property than hunting for all the instances of a hard-coded value.


odijk
Giga Expert

Yes, it works


Yes, it is easier


Yes, if the query is simple and doesn ´t return a lot of data the performance is similar



BUT



The code you create is not reusable.


You do send irrelevant information back: instead of only the relevant attributes, you send all information of the record(s) back.


You cannot always use it: As your dataset grows, it is possible that the resultset also grows and the page slows down.


You don ´t follow ServiceNow Best Practices. Because of this, future debuggers may be confused.