Why is my SaaS application so slow?
Summary
When the problem is outside of your network, solving it can become much more complicated. BGP, traceroute, packet analysis and synthetic monitors all come into play.
Many companies today rely on SaaS connections in order for the business to function. Some users simply can’t operate in their job when an application becomes unavailable. When hundreds of users are impacted, this can cost a company serious money.
That’s why keeping a proverbial finger on the pulse of application performance is generally worth the effort. But, it isn’t easy. Many popular SaaS applications are delivered from hundreds of locations around the world. To properly monitor them, it’s paramount to find out which servers your end users are connecting to.
Start with the desktop
Because SaaS applications are web-based, browsers can introduce problems. Most companies have a preferred platform (e.g., Chrome, Internet Explorer, Firefox, Opera). Make sure you are using the corporate standard. However, sometimes I try other browsers at the beginning of the troubleshooting effort. It helps me gain confidence that the problem isn’t the browser, or is it?
How many browser extensions do you currently have running? Some extensions consume resources and slow down web browsers. Try temporarily uninstalling all of them to see if performance improves.
Do you have any active tabs that are consuming resources even when you aren’t on the tab? Just for testing, close them. The more things we can eliminate, the faster we can overcome the problem and get back to work.
While you’re at the browser, clear cached files and cookies. Sometimes these files get corrupt or cause wacky problems. If you delete them, the next time you connect to any SaaS, the browser will just download them again, so have no fear. Delete them and eliminate another possible source of the problem.
It might seem like a “d’oh!” question, but: is it just one SaaS application that is slow, or do all the sites that you visit seem to be crawling? If it’s all sites, the problem is probably not the application. Let’s check some other basics. Are you running the OS with the latest patches? Run Task Manager (or Activity Monitor for MacOS), and look for applications that are consuming excessive resources. Shut them down and try working with my SaaS application after making some or all of the above changes.
This is sort of a long shot, but are you using a corporate DNS server? You might try temporarily switching to a public DNS like Google’s 8.8.8.8. DNS lookups can introduce significant latency on new connections.
Before you leave the desktop, launch a command prompt and execute a tracert to see if a particular hop in the path is introducing excessive latency.
Notice above that the routers used in the connection are looking pretty snappy. I’m not seeing any glaring issues in the path.
Next, point your browser to www.speedtest.net and run the test from at least two computers sharing the same internet connection.
Make sure that both devices are using the same server. Notice the arrow above in red. When troubleshooting SaaS connections, we want to make sure we’re staying consistent especially since internet traffic is bursty in nature.
If you “ain’t afraid of getting dirty,” use the Wireshark packet analyzer to see if your connection to the SaaS applications’ IP address is suffering from any packet loss. Even a 3-6% loss will lead to lots of retransmits and could be noticeable in your end-user experience. But if you are afraid, maybe find a good YouTube tutorial on Wireshark, as you may find that it isn’t that tough to familiarize yourself with these types of tools.
Check your local network
If you’re working from home, could it be possible that you’re competing with other local devices for that precious, limited bandwidth? If you don’t have fancy tools that tell you who is communicating through the router, take all other internet capable devices offline. Nowadays, so much is connected to the web (phones, tablets, computers, TVs, watches, radios, vacuums, security systems, refrigerators, small IoT devices, neighbors, even boat radios down at the dock). Most of these devices phone-home and auto-receive software updates. All of these devices could be introducing a calamity of problems.
If you have access to your local router, login and see if you can give connections to your SaaS application a priority. I would avoid giving your entire device high priority as other applications on your device could be consuming the pipe, and you don’t want them competing with high-priority, work-related applications.
Communicate
Check with the SaaS application
In the effort to exhaust all possible reasons that it could be slow, it’s probably wise to take a few seconds to check Downdetector. It’s just user status “up” or “down” reports that don’t share all of the juicy details that we’d like to see (e.g., CPU, memory, latency, packet loss, jitter, etc.), but it can give you a clue if it’s a local or widespread problem; or in other words, something you can do something about or not.
Check with coworkers
After you’ve completed some of the above, maybe it’s time to send a message out on Slack to see if other internal users are suffering from the same performance issues as you. Your coworkers may have some suggestions that aren’t listed above. If they respond with something like “yeah, I’m noticing it, too,” make note of this because if the problem keeps recurring, it could be time to contact IT to see if maybe you can connect to a different server.
What next?
Here are two things to keep in mind as you step through the above tactics for trying to determine why your SaaS application is so slow:
- The investigative techniques provided above will often uncover issues that you were not aware of (e.g., excessive browser extensions, unknown devices on your network, patches that should be applied, etc.)
- The problem may not be yours to solve. As stated earlier, repeated slowness issues should be reported to the help desk.
When the source of the problem is outside of your network, solving the issue can become much more complicated. For example, after thorough review of the traceroute and the BGP topology, a peering connection at the local IX could resolve the issue.
In other cases, synthetic monitors can be deployed to collect historical data on issues related to slowness. Loaded with historical information on which devices in the path introduce latency, packet loss and jitter, service providers can be contacted and urged to update the hardware and connections at the specific locations where the problems are being introduced.
These advanced troubleshooting techniques require special tools that help ensure that the entire, end-to-end cloud infrastructure is capable of delivering the quality of experience you’re looking for when logged into a SaaS application. To learn more, reach out and ask about the Kentik Network Observability Cloud.
