Six common performance pitfalls in Service Portal and how to avoid them
The purpose of this article is to share several scenarios that can lead to performance problems related to the service portal, how to diagnose the issues, and how to avoid them.
6 Common Causes of performance issues in Service Portal
Internet Explorer has several known issues related to memory management which can cause performance problems in service portal. Read more about these issues and the best practices for avoiding them here: Best practices for avoiding memory leaks in Service Portal when using Internet Explorer.
Auto-refreshing widgets can cause major performance issues. This is usually seen instance-wide in the form of semaphore exhaustion caused by a high number of calls to /sp/rectangle/.
This topic is addressed here: Are your auto-refreshing widgets causing instance slowdowns? Know that there is not really any way to do this without impacting system performance in some way.
Server scripts using large datasets or inefficient queries
Another common cause of performance issues in the portal is working with too much data. In extreme cases, this can run an instance out of memory, but it usually causes pages that widget is used on to load slowly. To avoid issues here, ask the question, How much of this data do my users actually need to see? For example, users probably don’t need to see every incident they have ever opened, just the ones that are open now.
What is the issue with large data sets?
There are a few reasons why large datasets are problematic:
- Querying the data, evaluating ACLs, and running business rules take time. This is true anywhere in the platform, of course, but it is no less true in the portal.
- The data is sent to the controller via the $scope.data object. The size of this object has a direct relation to the amount of time it takes to JSON encode, send via HTTP, and then unpack in the browser.
- If the system has to iterate through the data and do some processing on each record, this can be very expensive in terms of CPU cycles. This is true anywhere but keep it in mind when designing a portal.
What are the best ways to avoid processing large amounts of data?
- Use effective filters to show users only the data they really need.
- Do the minimal amount of processing to the data that is possible.
- Isolate widgets that require a lot of data or processing to their own separate pages in the portal. This way, the other pages that do not use as much data won’t be affected.
Scripted menu items
Scripted menu items are one of the most useful features in the Service Portal but, just like the server script in a widget, showing too much data can cause performance problems. Remember, these scripts run every time a user navigates in the portal, having an inefficient script in a menu can cause every page to load slowly in the portal.
For the most part, the technical reasons why this is problematic are the same as described for a server script so are the ways to avoid issues. These add loading overhead to every page on the portal so it’s likely to see the impact of a bad query in a scripted list menu item more quickly than to see the impact of a bad query in one widget instance.
Loading large files and attachments
Another place customers commonly run into performance trouble is loading large files and attachments. In many cases, these files are high-def media files or fonts stored in the sys_attachment table. In general, these take a little longer to load but it isn’t seen as an issue because users expect large, high-def files to take a little longer. If a portal is loading a lot of these files, or has several large fonts files being re-loaded in different parts of the portal, it can be a problem. One example is embedding an encoded image into a page’s CSS. This CSS may be included in the response to several different HTTP requests that are made when loading the page and can cause those requests to take longer.
Record watchers on a portal page can lead to performance issues if you are not careful. Using too broad of a filter, or placing record watchers with static filters on a page that gets a lot of traffic can be very troublesome. Each update to a record matching that filter will trigger a call back to the server so if you have a lot of users watching the same filter, then a single update can potentially cause semaphore exhaustion so it is important to fine tune these filters as much as possible. For more information on how to do that refer to this article: Fine tuning Record Watchers in Service Portal
How to diagnose performance issues in Service Portal
Use the SP Page Performance Diagnostic script. This can make it very easy to determine which widget(s) are slowing down your page load: How to identify a slow widget on a page
Try it in the platform. If something in the portal is slow, try it in the platform UI. In many cases, people spend a good deal of time troubleshooting why something is slow in the Service Portal without realizing that it is slow everywhere else too. That can drastically change the direction in troubleshooting. It is important to know right away if it’s really an issue specific to the portal or one that's a platform-wide performance problem.
- Test your queries in scripts background. If they're slow or return a huge amount of data in scripts background, they will do the same in your service portal widget as well.
Try another browser. Since certain browsers handle things differently, try to reproduce the slowness in a different browser. This is especially important if Internet Explorer is being used, because there are a lot of known issues with it.
Observe whether the slowness is in all pages of the portal. To narrow down some of the issues discussed above, check to see if all pages in the portal are slow. If so, look at the header menu to check if scripted lists are an issue. Also, check and see if the theme is loading any large font or image files.
Observe whether the slowness is on one page across all portals. If a certain page or group of pages loads slowly in every portal, then the issue probably isn’t the theme or scripted menu items unless the same ones are being used in all portals. If they are, try opening the page in the $sp portal (/$sp.do). This opens the page without any portal, so there is not a theme or header menu on the page. If that page still loads slowly, then focus on the widgets on the page to see which one might be causing the slowness.
A quick note about HTTP requests: Service Portal is a single-page application and most of the communication with the server is done via REST. This makes it difficult sometimes to know where the request came from. One of the most common requests is to /api/now/sp/rectangle/ followed by some sys_id. This is from a widget making a call to the server via server.update() or some similar function. That sys_id is the widget instance making the request. Knowing that makes it much easier to determine which widget causes the slowness.
Look at the syslog table. With large JSON objects causing slowness, oftentimes this produces a warning in the syslog table about a large JSON object. If these warnings are visible when the portal page is loaded, or when performing whatever action is causing slowness, this is a good indication that one of the widgets is working with a very large dataset that may need to be trimmed down.
Additional resources for performance issues
For more information on troubleshooting performance issues, here are a few blog posts to review:
- 5 Ways to Troubleshoot your Instance Performance
- Six Ways to Improve the Performance of Client Script
- Debug slow performance on the client side using Chrome
This article was created from a post in the serviceNow community Six common performance pitfalls in Service Portal and how to diagnose them