Faster Request Response

Tags:
Categories:

Paid users using AdGuard’s private service have the following DNS request path:

Based on the path, the fastest response scheme can be analyzed.

Local Cache Hit

The fastest response is a local cache hit. Since the local cache is at the memory level, it is very fast, taking only a few microseconds.

This is controlled by the TTL (time to live) value of the DNS response, typically ranging from a few minutes to several hours, indicating that the query result is valid during this time and does not need to be queried again.

You can set the minimum TTL value in Control Panel -> Settings -> DNS Settings -> DNS Cache Configuration -> Override Minimum TTL Value. Increasing this value extends the cache time, allowing the system to use the local cache more often. The typical TTL value is 600 seconds.

However, since this site also has filtering capabilities, if the service you need is mistakenly blocked by ad rules, you won’t be able to access it immediately even if you temporarily disable encrypted DNS, because the local cache result has been modified by the filtering rules. Therefore, setting it to 60 seconds is a safer value, ensuring that in rare cases, users won’t have to wait too long after disabling encrypted DNS due to misblocking.

AdGuard DNS Server

Currently, this site uses Alibaba Cloud servers located in Hangzhou, which can meet the low-latency needs of most users in the eastern region. As the business grows, servers will be added across the country in the future.

Server Cache Hit

By default, 4MB of DNS cache is set for each user, which is sufficient for a household based on experience. Freely modifying this setting may lead to forced termination of user services, and this site has blocked the modification entry for this setting.

Upstream DNS Server

Due to the use of Alibaba Cloud services, the upstream DNS service also uses Alibaba Cloud’s DNS service, which is very fast, typically returning results within a few milliseconds.

Users have three ways to request the upstream DNS server:

  1. Load Balancing: This site uses load balancing by default, automatically selecting the fastest server to return results.
  2. Parallel Requests: This site currently does not restrict the use of parallel requests.
  3. Fastest IP Address: This setting is currently meaningless, and this site has blocked the modification entry for this setting.

Here’s why the Fastest IP Address is meaningless: the fastest IP needs to be chosen by the device actually accessing the service. When the AdGuard service runs in Hangzhou and the user is in Beijing, AdGuard will think the IP address in Hangzhou is the fastest, but in reality, the user’s access to services in Beijing is the fastest. Choosing the Hangzhou IP address would actually increase latency. Therefore, this site has blocked the modification entry for this setting. This setting might be useful in a user’s home network but is meaningless in public services.

Many factors affect network experience, such as server bandwidth, network congestion, server load, and network quality. Choosing the fastest IP address does not guarantee the fastest response speed; latency is just one factor, not the only one. To prevent users from setting it incorrectly and causing a decline in service quality, this site has blocked the modification entry for this setting.

Rule Filtering

The most commonly used mode is the blacklist list, from which users can choose. The blacklist hit uses a hash algorithm, so regardless of the number of rules, the hit time is O(1), and users do not need to worry about the hit time being too long due to a large number of rules.

However, after rule calculation, they are stored in memory, with each user’s service memory usage limited to within 300MB, which can meet the needs of most users. If a user has too many rules, it may lead to insufficient memory, causing the service to restart repeatedly and resulting in service interruption.

This site has temporarily blocked the use of third-party rules to avoid users introducing too many rules. In the future, with better restriction methods, the use of third-party rules will be reopened.

Summary

To achieve faster request responses, users can:

  1. Appropriately increase the minimum TTL value to increase the local cache hit rate.
  2. Set an appropriate DNS cache size (pre-set value).
  3. Choose to create a service in the geographically closest city (awaiting business development).
  4. Choose load balancing for no overseas needs; choose parallel requests for overseas needs.
  5. Use a blacklist rule that suits you, avoiding introducing too many rules.