Skip navigation

In my last blog post 5 Ways to Troubleshoot your Instance Performance I have shared a few tips which enable administrators to diagnose performance issues. As a performance engineer, homepage performance is one of the most commonly diagnosed problem areas we assist customers with. Heavy home pages can lead to overall instance performance degradation.


Inefficient homepages lead to poor end user experiences e.g:

- Slower logins

- Poorer instance performance at peak login times

- Poor performance on form submission (where redirect to occurs)

- Homepage auto-refresh functionality ( can compound the problem where inefficient home pages are concerned


While designing home pages, ask yourself which information do you need to rendered as a part of home page loading and which one is not?


How to identify if your instance performance is suffering due to a heavy homepage

Hefty home pages can result in slow load times, which may lead you to think there's something wrong with your overall instance. Administrators can review the transaction logs and look for URL starts with "/" and check through the response times. Sort the response times z > a and look for the usernames with highest response time.

identify instance performance.jpg


This will help to pinpoint the users with heavy home pages. If the  response times of multiple "" transactions is high ( > 8-10  seconds), that could be impacting the overall instance and causing a load on the database as well.


Homepage best practices to improve performance time

  1. Avoid having too many gauges in one dashboard, especially from big tables. Aim for no more than 4 gauges per page - split onto other pages if more needed.

        A dashboard should be designed with gauges that show focussed and pertinent items of data that should invite a user to drill down further if needed.

   2.  As an admin user, make use of debug options  by enabling "Debug home page rendering."                                                                                                                                                       

    1. Impersonate one of the users with a heavy homepage. It will display the time each widget is taking. Remove heavy widgets and run it as a report, or see if there are ways to optimize the performance of those reports by adding additional filters.

  3.   Avoid frequent homepage refresh.

    1. Setting auto refresh for every 5-10 seconds could result in session synch waits. Doing the frequent refresh by multiple users can lead to massive database workload.  Refresh option can be entirely disabled by creating the "glide.home.refresh_disabled" property and refresh intervals can be customized using "glide.home.refresh_intervals" property.

  4.   Make use of multi threaded homepage rendering, see Parallel Homepage Rendering Explained for more details.

  5.   Design and set a default system homepage preference so that users who haven't selected a specific home page will land on a lightweight default homepage.

  6.   Always report on current (active=1) data - gauges that show trending on historical or inactive data should be moved to "Reports" wherever possible

    1. For example, try the Incident > Resolved, then try it again after adding active=true to the filter. For more tips, refer Improve performance by displaying "just enough" data

  7.   Think carefully about allowing non-admin users to create their own custom home pages - if this is allowed ensure users have a good understanding on how to design good home pages

  8.   Do not put slow gauges on the same page as fast gauges - defeats advantage of multi-threading which the platform supports



For additional information on homepage performance see:

Homepage caching

Change the parameter for parallel homepage rendering

Configure homepage cache properties

Troubleshoot reports on a homepage for performance

How do you enhance Homepage performance in case of gauges ? i) Increase the number of gauges ii) decrease refresh time of gauges iii) Off Refresh button/delete groups

How to improve the performance of home page

Best practices for Import Set performance strongly recommends the usage of indexed fields as coalesce fields. In an import, coalescing on a field (or set of fields) means the field will be used as a unique key. If a match is found using the coalesce field, the existing record will be updated with the information being imported. If a match is not found, then a new record will be inserted into the database. If the indexes are missing, it can lead to poor performance issues especially if large amount of data processing is involved. Starting with Fuji release, Administrators have the option to create indexes on coalesce fields from the user interface.


Example of how to create indexes on coalesce fields from the UI:

Let's say you have an admin that is creating a transform map and you identify a coalesce field(s).


As soon as a coalesce setting is changed, users will be prompted with a message saying "Coalesce settings changed. After all coalesce fields are configured, use the Index Coalesce Fields related link to check if a new database index is required."  Hop down to the related links and click on "Index Coalesce Fields."


Clicking on "Index coalesce fields" will take us to the "create a new index" screen where the admin can confirm the index and schedule it for creation in the system. Here, you can generate a new index that will continue to work while the index is being run. When the index is finished, you will receive a confirmation email. Just click "Ok" to continue.

index.pngTrying to coalesce on non-indexed fields could cause performance issues. To avoid performance issues on the database, you should coalesce on a field that is unique and already indexed. Index creation can be confirmed from "Tables and Columns view by going to System Definition > Tables & Columns and looking for the blue "i" icon.


What if the coalesce fields are already indexed?

If at least one of the fields is fixed, no additional indexes are required. You will be notified that the fields are already indexed.


This feature can be used for existing and new transform maps. It can be initiated any time to create indexes on coalesce fields. If there are no coalesce fields defined in the transform map, no message about index creation will be displayed. Existing transform maps will not have indexes created automatically, administrators need to click the link to make use of the feature. If an admin edits an existing transform map with a coalesce field, following message will be displayed to prompt the index creation.

Screen Shot 2015-08-09 at 5.22.59 PM.png


This feature will help administrators to proactively create indexes before running into import set related performance issues. There are other ways to create indexes on Fuji instances. Please check out the latest blog post by Bill Tang where he shares best practices and tips on Improving your ServiceNow instance performance by creating database indexes via the User Interface.

Filter Blog

By date: By tag: