Application Performance Monitoring (APM) for HTTP URLs
Since its beginning, Obkio's solution focused on Network Monitoring with the Network Performance Monitoring and Network Device Monitoring feature sets. With these features, IT teams can monitor and troubleshoot intermittent network issues with precise network metrics including some Quality of Experience (QoE) metrics based VoIP Quality and MOS Score.
The main goal of IT teams is to provide a fast, secure and reliable infrastructure to the end-users so they can work efficiently without productivity lost due to slow IT. But problems will occur and IT teams will need to troubleshoot quickly to reduce the impact on the users.
It's easy to blame the network for all kind of slowness but it's not always the source of the issues. Obkio's Application Performance Monitoring (APM)tool for HTTP URL monitoring feature is available to help IT teams troubleshoot specific websites and make sure they are responding fast.
The Application Performance Monitoring (APM) HTTP monitoring feature is very simple but give tremendous information to help troubleshoot and pinpoint the so-hard-to-find intermittent problems. As its name suggests it, the APM HTTP feature tests a single HTTP URL periodically to extract performance metrics for detailed and real-time URL monitoring. Let's check the details with a real example, a test to https://obkio.com that is executed every 60 seconds.
The previous graph shows the network performance from one Monitoring Agent to the server hosting https://obkio.com. The monitoring agent could be a software or hardware agent but it can also be a Public Monitoring Agent such as the one hosted at AWS, Microsoft Azure or Google Cloud.
The five metrics in the graph tooltip are the five steps to download the content of a single URL.
The DNS resolution delay to resolve the domain name into an IP address. By default the OS DNS Servers are used but it's possible to change them in the APM Template Advanced Parameters. A long DNS delay can means a few things:
- The DNS request has been lost (maybe due to heavy packet loss) and needs to be resent.
- The first DNS server used is down and after a timeout another DNS server has been queried.
- The DNS entry has a very short TTL and the authority DNS server needs to be queried again.
- The DNS server is overloaded and is not able to respond quickly.
DNS is key to URL monitoring, which is why a DNS problem must be addressed quickly. In some cases, it can affect all the users, like for example, in the case of a down or wrong configured DNS server.
The TCP delay is the time taken by the TCP session establishment with the TCP 3-way handshake. A long TCP delay is usually a sign of network latency or packet loss. For the majority of the servers, the TCP handshake is done by the OS Kernel and is very fast compared to the SSL and WAIT delays. This delay can be reduce by using a CDN, more on that later in the article.
The SSL delay is the time taken by the SSL negotiation with the SSL handshake. An overloaded server will result into higher SSL delays. This delay can be reduce by using a CDN, more on that later in the article.
Waiting for the server to respond to the request. This is often called the Time to first byte (TTFB) metric. This is a very good metric that indicates the server load and the time it takes to generate the page. If the page is using a CMS (Content Management System) with a database behind it, all the delay to get the data in the database and render the page is included in this WAIT delay.
One of the most most common tactics used in URL monitoring is downloading. Download the content of the page, and if this page is a simple HTML file, the download will be very fast. It can be much longer if the content of the download is a file.
The last information provided Application Performance Monitoring software tooltip is the HTTP Status Code of the request. The expected status code is 200. If the status code is 301 or 302, the URL is redirected to another page. For example:
- http://www.google.com is redirected to https://www.google.com (note the S in HTTP)
- https://google.com is redirected to https://www.google.com (the www is added to the hostname)
To really test the performance of an URL, it is recommended to use the final URL and avoid any 3xx status codes.
For all the metrics mentioned above, a degraded network with high latency and/or packet loss will result in longer delays than usual. This is why the Network Performance Monitoring features should be used to monitor and baseline the network performance metrics. This way, it's very simple to find out if bad APM HTTP monitoring results are the fault of the network or moreso of the application/server.
It's important to understand that the APM HTTP monitoring feature is executing only a single HTTP request and it is NOT interpreting the downloaded content. It will not load images, styles or scripts inside a web page. The engineering team is working on an APM Web Browser monitoring feature that will launch a website into a browser and will load it completely, including compiling and executing all the scripts inside a page. It is with that APM Web feature that we discovered the last Microsoft Login Failures Affecting Office 365 and Azure.
This new Application Performance Monitoring (APM) Web feature is available to some customers during it's final development stage. If you are interested in trying out the new solution for yourself, contact us and we will include you in the beta program!
With the APM HTTP feature, you can download large files that will test the throughput of the Internet connection. Below is an example of downloading a large file from OVH Static Download Files.
This APM HTTP Test is limited to 50 Mbps in the APM Template Advanced Parameters. The second graph shows the download speed for the each execution of the test.
The downloaded file is never stored into memory or disk so the test can be used with files of any size. However, be careful, without a rate limit configured in the Advanced Parameter, one can saturate the local Internet connection and create congestion.
The APM HTTP feature can be used to test HTTP API Calls. In the APM Template Advanced parameters, you can change the default HTTP Method GET for all the possible action. It is also possible to add custom HTTP headers to the request. In the custom headers text area, each new header must have it's new line and the format is "HEADER: VALUE".
The CDN will offer the following advantages:
- By using distributed servers across the globe, the latency between the server and the user is lower, which results in better performance for the TCP and SSL delays.
- By caching the response, it will reduce the load on the backend servers and will reduce the WAIT and DOWNLOAD delays.
To accelerate the DNS delays, a global DNS server solution such as AWS Route 53 reduce the delays for users across the globe.
The Application Performance Monitoring HTTP tool is available right now for all users. Try Obkio today by signing up for our free 14-day trial!