Improve performance by displaying "just enough" data

[Alex North]

"More is better." There's a statement to spark a debate if ever there was one. Arguably in some situations, this is true. For example "I have more time to do the things I want because ServiceNow helped me streamline my department's work." When it comes to choosing how many rows you want to see in each list in the application, it pays to be a bit more discerning. Just because you "can" display 1,000 rows in a list does not mean that you "should." If your users are complaining of slow form load times or that the system is slow to save records and show them their work list, you may be able to improve performance by displaying "just enough" data.

One of the ways ServiceNow really adds value and helps productivity is by having data readily available from any given screen. If you have used a Reference Field on your form to associate a user or a CI to an incident, you can hover over the little 'i' and get a preview of that record. This is made possible because the relationships with the Reference Fields are built prior to the form being rendered.

Not only is it possible to click through to related records from forms, it is also possible to access this information through list views. This is where things have the potential to slow down.

 

Row count flexibility

Let's say it takes 100 ms to build the relationships for a single record. The smallest number of rows which a user may display (out of box) in a list is 10. This list will take at least 1 second to render (100 ms x 10 record = 1,000 ms = 1 s). Out of box, systems have the following "Items per page" drop down options: 10, 15, 20, 50, 100. In this example, a user who had chosen to return 100 rows in his list will have to wait 10 seconds for that list to come back (100 ms x 100 records = 10,000 ms = 10 s).

User selecting 20 rows per page

The question then arises "If returning large numbers of rows is detrimental to performance, why let users do it?" The short answer would be "To offer flexibility to users." The slightly more verbose answer would be that we allow users to choose to view as many rows in a list as they feel they require to complete the task at hand. The number of rows which will be displayed to a user in a list is stored in the sys_user_preference table as the "rowcount" preference. This preference will be applied for this user against all lists in the system (list view, related lists and embedded lists on forms).

Consider how you have designed your forms. Making the related tasks / changes / CI information available to refer to as related or embedded lists can be a really convenient way to present additional information to users. If users have elected to display hundreds of rows in a list, the system has to pull all that data from the database and then render it on the screen. Even though the render is asynchronous (post Dublin), this activity still exerts load on the database, which has the potential to impact all users of the platform.

Selecting row count based on the user

Now consider how users, particularly ITIL users, navigate around the system. In all likelihood your ITIL users will be working from a list, or a homepage with gauges which list tickets or tasks. When ever the user saves the record they are working on, they will be taken back to the last page (typically the homepage). If that homepage has hundreds of rows being returned, the user has to wait x seconds for that page to render, which can lead to a sluggish user experience.

When implementing and managing your ServiceNow instance, it is useful to think about how much information is useful to display to your users on screen. Depending on the user's screen resolution, you are likely going to be scrolling down the page after about 20 rows, yet you will have had to wait for the relationships for all of the records (including the ones which will be rendered off screen) to be generated prior to the page loading. It is probably as efficient to have your users click for the next batch of 20 as it is to scroll down a page which took a long time to initially render.

Remember that if a user requires more information, they could export the list to various file types (CSV / Excel / PDF etc). If the same information set is required frequently, then building a Report would be a better option that changing the "Show" option on the list [and then forgetting to change it back to something smaller, 20 is default].

Finding row counts preferred by users

To learn how your users have configured their rowcount preference, go to the sys_user_preference table and filter all preferences where name=rowcount. I personally find it easier to then export that result to CSV so that I can get a count of how many users have selected which option.

https://yourinstance.service-now.com/sys_user_preference_list.do?sysparm_query=name%3Drowcount

If you find a large percentage of your user base has chosen a high (subjectively 50 or more) number of rows to be displayed in lists, you may want to revisit what options you are making available to your users and why. The "Items per page" drop down options are set under System Properties > System, toward the bottom of the page. The property which defines the default preference is glide.ui.record_count. ServiceNow Technical Support can assist you with updating user preferences en masse, should you wish to reset them back to 20 rows per page.

Wiki reference: System Performance Best Practices