:Website access is slower after acceleration using Alibaba Cloud CDN

Disclaimer: This article may contain information about third-party products. Such information is for reference only. Alibaba Cloud does not make any guarantee, express or implied, with respect to the performance and reliability of third-party products, as well as potential impacts of operations on the products.

Problem description

After using Alibaba Cloud CDN to accelerate content delivery, the website access speed is slow. Due to many factors affecting slow access, how to analyze and locate problems, optimize website speed and solve problems is a very important topic, which is introduced in detail in this paper.

Solution

Alibaba Cloud reminds you that:

• Before you perform operations that may cause risks, such as modifying instance configurations or data, we recommend that you check the disaster recovery and fault tolerance capabilities of the instances to ensure data security.
• You can modify the configurations and data of instances including but not limited to Elastic Compute Service (ECS) and Relational Database Service (RDS) instances. Before the modification, we recommend that you create snapshots or enable RDS log backup.
• If you have authorized or submitted sensitive information such as the logon account and password in the Alibaba Cloud Management Console, we recommend that you modify such information in a timely manner.

If the access speed of your website is slow after you use Alibaba Cloud CDN, troubleshoot the issue as follows.

Analysis

Before troubleshooting and analysis, we recommend that you understand how CDN is accelerated. For more information, see CDN acceleration principles. CDN adds cache nodes to the existing network to distribute resources retrieved from the website server to the network nodes closest to the requesters. In this way, user-side clients can directly access the nearest CDN nodes and hit the requested resources. This reduces origin retrieval and improves the access speed of the website. Therefore, the possible causes of slow access can be simply summarized into the following types:

• Network errors on the client, such as insufficient downstream bandwidth and incorrect DNS configuration.
• The network connection between the client and the CDN node is poor, and the network latency is high.
• The CDN node is abnormal and the response speed is slow.
• The resource content is relatively large, causing the download to take a relatively long time.
• When CDN returns the result to the origin site, the return network is poor.
• The origin itself responds slowly.

By collecting some problem phenomena and information, we can further analyze and preliminarily determine the direction of investigation, which is also a very important link.

1. First, check whether slow access exists in the whole network, or whether access from individual users or the network operators in a certain region is slow. You can use some platform for tone detection. For free platforms, see 17 tests. For paid detection platforms, see listen to cloud and Bo. These platforms can be used to set detection machines in a region and an operator's network to detect them with higher accuracy:
   • If only a very small number of users had poor access, this situation might have a strong correlation with the user-side network, which is probably a user-side network problem.
   • Determine whether abnormal users are concentrated. For example, a large number of users in a city have abnormal access requests, but access requests from China Unicom and telephone companies are normal. This situation may be related to the operator networks in the region. Some tone tools can be used to perform detection with detection machines in the region.
   • If users across the network have slow access issues, the origin may fail to respond or is configured because it is almost impossible to guarantee that all CDN nodes or networks in all regions have slow access at the same time. For example, check whether the selection of an accelerated area is incorrect, whether the request is dynamic, or cannot be cached, and whether the origin response is slow.
2. To check whether a request with slow access or exception is cached by CDN:
   • If the request hits the CDN cache, then there is no CDN back-to-origin, so CDN returns the cached data on the node directly to the client, which is not related to the origin site.
   • If the request is not found in the cache, check whether the connection from the client to CDN is slow or whether the origin site responds slowly.

Metric

Besides the common observation metrics, metrics that are used to accelerate content delivery vary with the scenario. You can learn how Alibaba Cloud CDN accelerates content delivery and how it is applied to your services by referencing these indicators. This helps you make adjustments and business decisions. Alibaba Cloud CDN documentation provides documentation on CDN measurement metrics. For more information, see CDN measurement metrics.

Information gathering

We know that a complete HTTP request must go through DNS resolution.>TCP connection>SSL Handshake (HTTPS requires an SSL Handshake)> client sends request>The process during which the server responds to requests. Understanding the process of the HTTP request will help us to analyze the problem at a deeper level. Therefore, it is necessary to collect some information on the client side. We can usually collect the following information.

Collect information about the client network and CDN node IP addresses.

Use the ping command to connect to the CDN domain and check whether the resolution is correct, and check whether the network connection between the client and the CDN node is smooth and whether the network latency is good. If the ping fails, you need to perform some link diagnostics. For more information, see link diagnostics. If it is a mobile phone client, it is necessary to use some third-party applications to assist in diagnosis. For example, Android can use "network multimeter", and iOS can use "iNetTools".

Collect client IP addresses and local DNS

In a CDN node scheduling policy, resources are scheduled based on the local DNS of the client. Therefore, it is important to check whether the local DNS of the client is set correctly. You can access the Kunlun diagnostic tool to obtain the client IP address and the DNS of the client.

Find the URL with slow access

You can open the developer mode of the browser and switch to the Network tab. After entering the URL, you can view all HTTP requests sent by the browser on the Network tab. Click Time to view the slow resources. In the Domain column, find the slow URLs under CDN.

Note: generally, a website loads many resources such as non-CDN URLs. In this case, some non-CDN resources can be accessed slowly, but CDN-accelerated resources can be accessed quickly. However, the entire website responds slowly because of non-CDN-accelerated resources. Therefore, sort the URLs by Time to check the slow URLs.

Collects the request headers and response headers of HTTP requests.

On the Network tab, click the Name of the Slow HTTP Request. The Headers tab displays the General Request, Response Headers, and Request Headers fields. Based on the request headers and response headers, we can know whether the request is a static request and whether it hits the cache.

Note: if it is a mobile phone 4G is slow, it is necessary to capture packets on the mobile phone side to obtain information, and this operation may have some difficulty for the average user. You can enable the mobile phone hotspot and connect the PC client to the hotspot to collect information on the PC client.

Collects Timing information for an HTTP request.

The Timing tab shows the time-consuming information for each part of the resource during the entire request lifecycle. For more information about Timing, see Understanding Resource Timing.

Common scenarios

After learning about CDN and the HTTP request process, you can basically find and locate some issues based on the preliminary analysis and client-side information. The following are some typical cases.

Case 1: poor network quality of a client-to-CDN node

When the client uses the ping command to test the CDN domain, the result shows that the network latency is high, and even packet loss occurs. In this case, you need to collect information screenshots of the client IP address, client DNS, ping, and MTR. The CDN scheduling node implements scheduling tasks through the DNS of a client. It can determine whether the scheduling is abnormal based on the client IP address, DNS, and the CDN node. The network latency and the specific delay can be seen in the network link node based on the ping and mtr information screenshots. This section describes two use cases.

Acceleration region settings error

Users in mainland China are resolved to nodes outside mainland China, or users from outside mainland China are resolved to domestic Countries. The specific scenarios are as follows:

Note: We recommend that you set the acceleration region to global in this scenario.

• If the CDN acceleration region is "mainland China only", then the scheduling domain of this domain name only has a CDN node in mainland China. When an overseas user visits this domain name, all requests will be scheduled to a CDN node in mainland China.
• If the acceleration region is global (excluding Mainland China), the domain only has CDN nodes other than mainland China. All users in mainland China will be directed to CDN nodes outside mainland China.

Client DNS settings errors

If the client-side DNS settings are incorrect, change the region of the domain to the DNS of the corresponding ISP.

• If a user uses China Unicom's DNS server, the user will send a request to the CDN node of China Unicom for long-distance scheduling, which prolongs the network link.
• A user of Guangdong Mobile uses the DNS server of Harbin mobile will cause the user to request to the CDN node of Harbin mobile, and the network link will be extended remotely.

Note: If the acceleration region and DNS are correctly set, and the network quality is still poor after CDN is correctly allocated and scheduled, collect traceroute and mtr information for further diagnosis.

Case 2: Low cache hit rate or frequent origin fetch

CDN accelerates the delivery of static resources by caching the static resources to the nearest CDN node. When you access a resource, the resource is directly retrieved from the cache without retrieving the resource from the origin server. A low Content Delivery Network (CDN) cache hit ratio increases the workloads on origin servers and causes low access efficiency of static resources. Therefore, the CDN cache hit rate directly affects user experience, and ensuring a high cache hit rate has become the core topic of CDN. You can select an optimization policy to optimize the CDN cache hit rate for the specific cause of the low CDN cache hit rate. For more information, see CDN cache hit rate. You can check whether the requested resource is cached based on the X-Cache field in the Response Header returned by CDN.

Note:

• X-Cache: The MISS field indicates that the requested resource is retrieved from the cache, and the requested resource needs to be retrieved from the origin server. X-Cache the MISS field indicates that the requested resource is retrieved from the CDN cache, and queried data is retrieved from the cache server.
• X-Swift-CacheTime: the cache duration allowed on the CDN node, that is, the cache duration of the file. If the value is 0, the request cannot be cached.

The phenomenon and optimization scheme of low cache hit rate or frequent back-to-origin are as follows:

• Slow first access to resources
  The first access to the origin server is slower than a direct access to the origin server. Because the first access to the CDN node has no cache, the CDN node needs to retrieve data from the origin server. We recommend that you use the URL prefetch feature. For more information, see prefetch URL to prefetch content from the origin server to the CDN node. Then, the content can be directly hit the cache when the user accesses the origin server for the first time, which improves the loading speed.
• Low Resource Page View
  A low resource page view. Files are not hot enough. CDN does not receive many requests, and no cache hit is available. CDN nodes share the resources of all CDN users. Therefore, a cache rule configured on CDN indicates the maximum cache duration of the resources on CDN. If your CDN domain name traffic is low, it may be cleared from the cache of the CDN node in advance. In other words, the cache is removed at the end of the popularity attribute. Popularity refers to how frequently a file is accessed on the node. When the file is not popular enough, it will be removed.
• Improper cache configuration
  The cache configuration is inappropriate, and the cache time is too short. CDN nodes frequently retrieve content from the origin server in the following scenarios:

• • When no cache rule is configured on CDN, a static file cannot be cached on the CDN node if the ETag and Last-modified response headers are not returned. For optimization solutions, you need to configure both response headers on the origin site or configure cache rules on the CDN side. For more information, see cache rules.
  • When no cache rule is configured on CDN, CDN uses the default cache policy. For more information, see default cache policy.
  • If the origin server is configured with Cache-Control response headers that are forcibly not cached, CDN will not Cache the resource even if a Cache rule is configured. This is because these response headers have a higher priority than the CDN Cache rule. If the origin site has any of the following rules: "s-maxage=0", "max-age=0", "no-cache", "no-store", "private", "Pragma: no-cache", CDN will fail to cache resources. You need to modify these response headers on the origin site. Change the status of the Nginx server to Public in the response headers that can be cached. For more information, see set Nginx cache policy custom cache policy settings.
• The URL carries variable parameters
  The resource access URL carries the parameters, which are constantly changing. When different URLs are used to access CDN, CDN considers this to be a new request (even if the two different URLs are actually accessing the same file and the file has already been cached on the node), and still pulls the requested content back to the origin. We recommend that you enable the parameter filtering feature. For more information, see parameter filtering.
• Large File Range back-to-source
  Some large files need to be cached, so we recommend that you enable the Range-based back-to-origin feature to optimize back-to-origin. For more information, see Range back-to-origin.

Case 3: slow access to dynamic requests

If a slow request is a dynamic request, when the client accesses the dynamic content, it must access the user's server each time. The server dynamically generates real-time data and returns it to the client. In this scenario, CDN cannot cache dynamic content that is changed in real time. Therefore, CDN Cache Acceleration is not applicable to the acceleration of dynamic content. Instead, the CDN node has to redirect the request for dynamic content to the origin server. As a result, CDN cannot accelerate the delivery of dynamic content. If your website or application has lots of dynamic content, for example, when you need to accelerate API operations, consider the following solutions.

1. Static and dynamic resources are separated from origin sites. The CDN domain name is used to accelerate static resources, whereas dynamic requests are accessed by a domain name that is directly resolved to the origin site.
2. To accelerate dynamic requests by using Dynamic Route for CDN, see Dynamic Route for CDN. However, it should be noted that Dynamic Route for CDN accelerates dynamic requests through dynamic acceleration technologies such as routing optimization and transmission optimization of Alibaba Cloud, so that a layer -4 link is optimized to access your server's origin site as fast as possible. If the response speed of the origin server is slow, in this case, it is still necessary to optimize the source station.

Case 4: slow origin response

When a request access speed is slow, if the request is a request that does not cache resources or a dynamic request, it must be returned to the source. However, the origin can respond slowly. In this situation, you can visit the origin server by binding the origin domain name locally, or test the response speed of the origin server with the domain name. The causes are as follows:

• The origin site performance is limited, and its processing speed is slow. For example, the bandwidth and CPU of the origin site reach bottlenecks, or the processing speed of the origin site program is slow. Therefore, the origin site needs to be optimized. If the performance is insufficient, you need to scale out the source station.
• The network of the origin site is relatively poor, or the origin site involves cross-border links. For example, users request CDN nodes in mainland China while the origin site is outside mainland China. Since the CDN back-to-origin links are also public endpoint to the origin site, cross-border links may be affected, because cross-border links involve different operators and overseas operators and need to take the internet exit, which is uncontrollable on the CDN side and the origin site side, and there is very little room for CDN unilateral optimization. It is recommended to deploy dual-source sites (overseas and domestic) to adjust the architecture and optimize.

Case 5: slow website homepage loading

When the client accesses http://www.example.com/ The browser requests the homepage. After the request succeeds, the server returns the HTML code to the browser. The browser then requests the required resources such as images, JavaScript, and CSS based on the returned HTML code. If the homepage is a dynamic resource or resource that does not need to be cached, CDN will process the request back to the source. Slow response time on the origin server can cause slow page loading and this request has a Pending status on the Network for a long time. For more information about whether hit is a cache hit, see Case 2: low cache hit rate or frequent back-to-origin.

In scenarios where the requested homepage is not cached and access speed is slow, the requested homepage remains Pending. When the requested homepage arrives, all static resources will be loaded soon.

Note: If the homepage is slow, it may be inaccurate to use platforms such as "Webmaster Tools" and "17 tests" to verify the CDN acceleration effect. If you set test address to http://[$domaini], the detection platform detects the homepage address but does not detect the static files on the website. You can verify the acceleration effect only if the URL is a specific static resource URL.

Case 6: large amount of resources loaded by a website

If a website loads large amounts of resources, you can use the performance optimization feature of CDN domain names. For more information, see performance optimization. This feature can reduce the size of the accessed files and improve the acceleration efficiency and page readability. Intelligent compression supports the following formats: text/html, text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, text/javascript, image/tiff, image/svg+xml, application/json, and application/xmltext.

Case 7: slow access by a carrier user in a region

The client has similarities with some problem scenarios. For example, during a certain period of time, a large number of China Mobile users in a city reported that access was slow or abnormal, while China Unicom users were normal. This type of problem is likely to be associated with the local operator network or the CDN node requested by the region. A common troubleshooting method is to collect ping information on the user side and confirm the network latency between the client and the CDN node.

In addition, according to the IP address of the CDN node requested by the user, you can bind to the CDN node for testing. The test method is similar to that of binding to the source Station to test. You can convert the IP address to the IP address of the CDN node. Before you test whether a node is bound, you can verify whether the node has slow response. If a response is slow, check whether the request hits the cache or whether the loaded resource is too large. If you cannot locate the problem, submit a ticket to contact Alibaba Cloud.

Application scope

• CDN
• Dynamic Route for CDN