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 home.do occurs)
- Homepage auto-refresh functionality (https://docs.servicenow.com/use/homepages/reference/r_RefreshTheHomepage.html) 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 "/home.do" and check through the response times. Sort the response times z > a and look for the usernames with highest response time.
This will help to pinpoint the users with heavy home pages. If the response times of multiple "home.do" 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
- 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."
- 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.
- 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
- 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: