While we have extensive documentation about caching, I wanted to know more about it. This week I sat down with Rafael Tucat, Director of Software Engineering at NetSuite, and asked him some questions about how SCA uses caching. By the end of it you should have a greater understanding of it, which will aid you in troubleshooting any problems you may have with caching.
Conversation with Rafael
What does caching do?
Caches store data that has already been requested so that it doesn't have to be fetched from the application servers every time it's requested. You can configure your site so that NetSuite uses a CDNs for this.
What's a CDN?
CDN stands for content delivery network. These are fast servers that are geographically distributed so that the closest ones to the user are chosen. All of it aims to improve the performance for the users of your site.
What sort of stuff is cached?
We have a list of items documented, but it is things like image files, search results, static content and SSP files. In general: as long as it's not dynamic content that requires NetSuite to execute code, retrieve data from a database, or requires a log in, then we cache it.
What isn't cached?
We never cache user-specific data. The CDN cache is only available on the shopping application, so anything in the checkout domain will not be cached.
Are CDNs the only caches available?
No. If you count the user's browser cache then there are three caches in total: the CDN, the NetSuite application and the user's computer.
How long are things cached for?
Unless you clear the cache, resources are stored for various amounts of time depending on what the resource is and what kind of cache you're talking about. A good thing about NetSuite is that you have quite a bit of control over how long you want to cache certain things (if you don't want to use our defaults). For example, with the CDN we have the following values available:
- UNIQUE – not cached. For example, sc.user.environment.ssp contains user-specific data and so must never be cached.
- SHORT – 5 minutes. The response from the search API uses this.
- MEDIUM – 2 hours. SuiteScript files (such as shopping.environment.ssp, which contains bootstrapped data) are cached for 2 hours.
- LONG - 7 days. Things like images and product reviews use this.
By comparison, the application cache has just the short and medium options.
What sort of symptoms would suggest that an issue is related to caching?
You might suspect a problem if you refresh the page and you notice one of the following:
- Seeing information on the site that isn't up to date.
- Creating a landing page and you get a 404 error when you visit it.
- Changing some settings that don't take effect.
So how do I deal with cache issues?
Well there are three things you can do.
Firstly, you can bypass the cache during development work. To do this you set up a secondary, test domain and then ensure you don't turn the CDN on for it. Then, instead of visiting your main URL, visit the test one instead.
Secondly, you can use the Cache Invalidation by URL option in the Actions dropdown on the Web Site Setup page. This is useful when you know of a specific URL (or resource) is causing you problems. Find the right URL to bust can be tricky, so we've got documentation on that too.
Finally, you can clear the entire cache. This action is also performed on the Web Site Setup page. Doing this will purge all file cabinet resources, script files, search API request outputs, etc., from the CDN cache. This is an intensive operation can sometimes take up to 30 minutes to complete and it will also degrade the performance of your site as all news resources have to fetched anew.
What about the application cache? Can we clear that?
Unfortunately, we don't offer a way to flush the application cache. The problem is that the cache applies to your entire NetSuite application, not just your SCA site. This is one of the reasons why we recommend setting up CDN caching.
Remember that shortening the cache times for resources will lower the performance of your site. It's effectively juggling act: increasing times improves performance, decreasing them gives you more real-time content.
Also the ability to clear a single URL is new in NetSuite backend UI, so you may not be familiar with it. However, it's very useful for clearing, say, just shopping.environment.ssp or changes to a landing page.
Plugin: Akamai Debug Headers
You may or may not know that we use Akamai for our CDN caching. So I spoke with one of our developers about this and he pointed me to a plugin available for Chrome called Debug Akamai Headers. What this does is as add a number of HTTP headers to requests along with some custom Pragma headers. When you inspect a HTTP request in the developer tools, useful additional information is given.
If you decide to install the plugin (which you do at your own at risk!) then the notes below will help you in working troubleshooting issues with the CDN.
After installing the plugin:
- Go to your site.
- Open the Network tab in the developer tools.
- Click on XHR.
- Select a service or item you want to investigate.
In the Headers tab there is now additional information in the Response Headers section. Here are some of the more useful things to look out for:
- X-Check-Cacheable — saying either
NO, this indicates whether or not the item is cached on the CDN. If it's NO then you know that it can't be a CDN caching problem as the resource came from NetSuite and not the CDN.
- X-Cache — there are a number of values this can have, common ones include:
- TCP_HIT — the item was in the cache and served from the disk. This is pretty normal.
- TCP_MEM_HIT — the item was in the cache and served from memory. This generally indicates that it was served slightly faster than from the disk.
- TCP_MISS — the item was not in the cache and so had to be served from NetSuite (or the source).
You can find a lot more about CDN caching and response headers on the Akamai Blog.
As a closing, I just wanted to add a tip for quickly testing whether something is cache-related or not. If you add a random (i.e., junk) parameter to the end of a request URL, the CDN will obviously not have it cached and will have to request the resource from the source. Note that you'll need to do this to the service itself, not the page URL.
So, for example, if I'm testing the API for my search results then I'll have a URL of something like:
If I add
&foo123=bar456 to the end of the request URL then the CDN will not have this cached and will have to return the version from the source, which I can then compare to the cached version to see if there is a caching issue.
Just remember to change the junk part of the URL each time as it'll likely be cached after you request it.
Posted on Wed, October 21, 2015
by Steve Goldberg and Rafael Tucat filed under