Six common performance pitfalls in Service Portal and how to diagnose them

jesseadams · ‎07-20-2017

Diagnosing Service Portal-related performance issues can be challenging. Service Portal is still very new technology and we all still have a lot to learn about troubleshooting when things go wrong. In this post, I will share some of the things I have commonly seen cause performance issues in the Service Portal so that if you run into performance issues, you'll know where to look in order to start diagnosing the problem and figuring out how to deal with it.

6 common performance issues in Service Portal

Service Portal and Internet Explorer

It's impossible to talk about Service Portal performance without addressing everybody's favorite topic — Internet Explorer. I have already written about how to avoid performance issues caused by IE's memory management issues at length here, so to summarize let me just say this: IE has several know memory leak bugs. It is no longer supported by Microsoft and these will not be fixed. As a result, we as developers have to take a few extra steps to ensure that we are working around these issues the best we can.

You can read about that in much greater detail in this post: Best practices for avoiding memory leaks in Service Portal when using Internet Explorer

Auto-refreshing widgets

This is another topic I have already written about but, again, it's impossible to talk about performance issues related to the Service Portal without addressing this. Auto-refreshing widgets can cause major performance issues. This is usually seen instance-wide in the form of semaphore exhaustion.

You can read more about this issue and how to avoid it here: Are your auto-refreshing widgets causing instance slowdowns? But for now, know it's a problem and you should avoid creating widgets that auto-refresh as much as possible.

Server scripts using large datasets or inefficient queries

One of the easiest ways to cause performance issues in your portal is by working with too much data. In extreme cases this can run an instance out of memory, but in most cases it simply causes pages that widget is used on to load slowly. A good thing to remember here is that the Service Portal was created as a visual layer on top of ServiceNow in order to allow users to easily find what they need, make requests, and check status of their open tickets. The trick to successfully achieving that without impacting performance is by asking yourself, "How much of this data do my users actually need to see?" For example, your users probably don't need to see every incident they have ever opened. They probably only care about the ones that are open now.

What is the issue with large data sets?

There are a few reasons why large datasets can be problematic here.

Querying the data, evaluating ACLs, and running business rules takes time. This is true anywhere in the platform, of course, but it is no less true in the portal.
Your data will be sent to the controller via the $scope.data object. The size of this object will have a direct relation to the amount of time it takes to JSON encode, send via HTTP and then unpack in the browser.
If you have to iterate through your data and do some processing on each record, this can be very expensive in terms of CPU cycles. Again, this is true anywhere but we need to keep it in mind when designing a portal.

So 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 as little processing to the data as you need to.
Isolate widgets that you know will require a lot of data or processing to their own separate pages in your 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. It's great to be able to display a dynamic list of a user's open requests that updates in real time, but just like the server script in your widget, you can run into trouble if you're showing too much data here. Remember, these scripts run every time you navigate in the portal so having an inefficient script in your menu can cause every page to load slowly in the portal.

scripted menu_requests.JPG

For the most part, the technical reasons why this can be problematic are the same as I described for a server script and likewise, so are the ways to avoid issues. It's worth remembering here, though, that these will add loading overhead to every page on your portal so it's likely you'll see the impact of a bad query in a scripted list menu item more quickly than you would see the impact of a bad query in one widget instance.

Loading large files and attachments

Another place where we commonly run into performance troubles is loading large files and attachments. In many cases these files are high-def media files or fonts that are stored in the sys_attachment table. In general, these may take a littlelonger to load but it isn't seen as an issue because we expect large, high-def files to take a little longer. What I want to point out here is that if you're loading a lot of these files, or if you have several large fonts files that are being re-loaded in different parts of your portal, it can be a problem. Especially if you have a very large attachment table.

Order Guides are slow

Similar to IE, you can't talk about Service Portal performance without bringing this up.

We have two known issues which cause order guides to be slow. In case you have not seen them, they are documented here:

The variable set issue is fixed in Helsinki Patch 10 and Jakarta, but the other is still being worked on by development. The issue with order guides having poor performance largely comes down to what I have already mentioned. Order guides containing a lot of items result in very large JSON objects being sent back and forth to the server constantly. These large objects take time to send and process and the frequency at which we send them can cause big performance problems.

One way to minimize the impact of this issue is to limit the size of your order guides as much as possible but in some cases, you may not be able to. If that is the case we do have a workaround documented for this issue here: Service Catalog on Service Portal

How to diagnose performance issues in Service Portal

Now that we know what things commonly cause performance issues, let's look at how to use that knowledge to diagnose performance issues in your portal.

Try it in the platform. A great first step to take if something in your portal is slow is to try doing the same thing 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 you take in your troubleshooting so it's important to know right away if it's really an issue specific to your portal or one that's a platform-wide performance problem.

Try another browser. Since we know that certain browsers handle things differently, try to reproduce the slowness in a different browser. This is especially important if Internet Explorer is your go-to browser because we know there are a lot of known issues with it.

Observe whether the slowness is in all pages the portal. A good way to narrow down some of the issues we talked about above is to check whether all pages in your portal are slow. If so, you probably want to look at your header menu to check if scripted lists could be an issue. You probably also want to find out if your theme is loading any large font files or anything like that.

Observe whether the slowness is on one page across all portals. If you see that 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 you're using the same one in all of your portals. If you are, try opening the page in the $sp portal. This opens the page without any portal so there won't be a theme or header menu on the page. If that page still loads slowly then you'll want to focus on the widgets on the page to see which one might be causing the slowness.

Look at your browser's dev tools. Two places to look here are the javascript console and the network tab. If you're seeing errors in the javascript console, they could be the cause of your slowdown and are worth tracking down. You may also see a large number of HTTP requests or one or more HTTP requests that take a long time to resolve. If you do, this is another good place to start your investigation.

javascript console.JPG

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 can make it difficult sometimes to know where the request came from. One of the most common requests you'll see is to /api/now/sp/rectangle/ followed by some sys_id. This will always come from a widget making a call to the server via server.update() or some similar function. That sys_id will be the widget instance making the request. Knowing that can make it much easier to determine which widget is causing slowness.

Look at the syslog table. I already mentioned that large JSON objects can cause slowness. Oftentimes this will produce a warning in the syslog table about a large JSON object. If you see these warnings when you load the portal page or perform whatever action is causing slowness, it's a good indication that one of your widgets is working with a very large dataset that may need to be trimmed down.

Remove widgets one by one. If none of the above help you narrow down the issue, try removing the widgets form your page one by one to see which one is causing the issue. The easiest way to do this is to set the widget instance to inactive.

Conclusion

Now that you know some of the common performance pitfalls with Service Portal and how to start diagnosing them, hopefully you will be well on your way to a lightning fast portal. I want to point out here that many of the areas discussed in this article are not inherently problematic things which should be avoided altogether. On the contrary, most are very good and useful features that I hope you will take advantage of, but like most things that are good and useful, you have to be careful not to overdo it.

Additional resources for performance issues

If you're looking for more information on troubleshooting performance issues, here are a few of great posts you can check out as well.

ServiceNow Community servicenow community