Adguardhome - Average processing time keep increasing

  • Thread starter Thread starter panks21
  • Start date Start date
  • Replies Replies 12
  • Views Views 7,458
P

panks21

Messages
250
Location
Delhi
ISP
Airtel Static IP
ACT Broadband
Looking for some Adguard experts here
I am running Adguardhome on a RPI4 with 4GB RAM and 64GB SDCard. This is my third attempt on Adguardhome. For some reason the Average processing time keeps on increasing as the days pass by and the users at home complain of slow responses. Following data is from past 24 days



Following is my DNS settings with Parallel requests enabled

Code: 
https://dns10.quad9.net/dns-query
tls://dns.google
tls://1.1.1.1
59.144.144.100
1.0.0.1

What else should I do to improve the response

I am on Airtel Static IP in Delhi
 
can't you restart the process every six hours using cron? that's what i do with transmission on my pi coz it overloads my pi2. though i suppose a dns server shouldn't struggle on a pi4.
 
@panks21 Which option are you using out of load balancing/parallel requests/fastest IP?
In the logs section, Have you checked which resolver is being used in queries?

These sort of response times are not extraordinarily high if it is using DoT/DoH.
 
On a relatively powerful VPS that can reach quad9/cloudflare in ~1ms I still see queries taking ~150-180ms. In another adguard instance at my home(cloudflare rtt, ~20ms, quad9 rtt ~50ms), I also see ~1000ms with DoT/DoH only and it was unusable so I had to fall back to using normal DNS.

I have DoT/DoH/normal DNS endpoints configured with parallel requests so it pretty much never actually uses responses from DoT/DoH endpoints because they take so much time.
 
@Sushubh Never tried that. Let me try it

@ishanjain28 Parallel Requests it is

Some tcpdump logs. 192.168.14.245 is the local address
It is sending requests to all of them

Code: 
root@pghomepi4:~# tcpdump -i eth0 -n not port 22 and not port 3000 and not port 8080
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:38:19.455415 IP 192.168.14.248.33868 > 192.168.14.245.5514: UDP, length 336
22:38:19.519105 IP 192.168.14.248.33868 > 192.168.14.245.5514: UDP, length 336
22:38:19.583410 IP 192.168.14.248.33868 > 192.168.14.245.5514: UDP, length 336
22:38:19.782617 IP 192.168.14.248.33868 > 192.168.14.245.5514: UDP, length 260
22:38:19.784382 IP 192.168.14.248.33868 > 192.168.14.245.5514: UDP, length 260
22:38:19.789908 IP 192.168.14.248.37121 > 192.168.14.245.3478: UDP, length 28
22:38:19.791622 IP 192.168.14.245.3478 > 192.168.14.248.37121: UDP, length 56
22:38:19.846562 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward], bridge-id 8000.e0:63:da:8c:f8:f0.8002, length 43
22:38:19.895837 ARP, Request who-has 192.168.20.254 tell 192.168.20.207, length 42
22:38:20.441383 ARP, Request who-has 192.168.14.254 (ff:ff:ff:ff:ff:ff) tell 192.168.14.246, length 46
22:38:20.452580 IP 192.168.20.219.49664 > 192.168.14.245.53: 6555+ PTR? 35.199.116.163.in-addr.arpa. (45)
22:38:20.453877 IP 192.168.14.245.53 > 192.168.20.219.49664: 6555 NXDomain 0/1/0 (133)
22:38:20.637120 IP 192.168.20.219.58503 > 192.168.14.245.53: 9753+ A? self.events.data.microsoft.com. (48)
22:38:20.637541 IP 192.168.14.245.53 > 192.168.20.219.58503: 9753 1/0/0 A 127.0.0.1 (64)
22:38:20.653687 IP 192.168.14.245.50588 > 8.8.4.4.853: Flags [.], ack 1402023301, win 501, options [nop,nop,TS val 1207203323 ecr 3756783629], length 0
22:38:20.661048 IP 8.8.4.4.853 > 192.168.14.245.50588: Flags [.], ack 1, win 265, options [nop,nop,TS val 3756798644 ecr 1207188315], length 0
22:38:21.441594 ARP, Request who-has 192.168.14.254 (ff:ff:ff:ff:ff:ff) tell 192.168.14.246, length 46
22:38:21.846654 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward], bridge-id 8000.e0:63:da:8c:f8:f0.8002, length 43
22:38:22.093707 IP 192.168.14.245.50554 > 8.8.4.4.853: Flags [.], ack 3404319225, win 501, options [nop,nop,TS val 1207204763 ecr 2783153437], length 0
22:38:22.099207 IP 8.8.4.4.853 > 192.168.14.245.50554: Flags [R], seq 3404319225, win 0, length 0
22:38:23.846901 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward], bridge-id 8000.e0:63:da:8c:f8:f0.8002, length 43
22:38:24.684114 IP 192.168.20.216.59303 > 192.168.14.245.53: 53584+ A? wpad.pghome. (29)
22:38:24.685143 IP 192.168.14.245.53 > 192.168.20.216.59303: 53584 NXDomain 0/1/0 (104)
22:38:24.827230 IP 192.168.14.247.55023 > 192.168.14.245.3478: UDP, length 28
22:38:24.828683 IP 192.168.14.245.3478 > 192.168.14.247.55023: UDP, length 56
22:38:24.963350 IP 192.168.20.219.52709 > 192.168.14.245.53: 24517+ PTR? 94.116.36.8.in-addr.arpa. (42)
22:38:24.963856 IP 192.168.14.245.53 > 192.168.20.219.52709: 24517 NXDomain 0/1/0 (107)
22:38:25.847121 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward], bridge-id 8000.e0:63:da:8c:f8:f0.8002, length 43
22:38:25.941228 IP 1.1.1.1.853 > 192.168.14.245.37422: Flags [P.], seq 839384746:839384770, ack 2380082463, win 66, length 24
22:38:25.941332 IP 192.168.14.245.37422 > 1.1.1.1.853: Flags [.], ack 24, win 501, length 0
22:38:25.941418 IP 1.1.1.1.853 > 192.168.14.245.37422: Flags [F.], seq 24, ack 1, win 66, length 0
22:38:25.983745 IP 192.168.14.245.37422 > 1.1.1.1.853: Flags [.], ack 25, win 501, length 0
22:38:26.387687 IP 192.168.20.225.38310 > 239.255.255.250.1900: UDP, length 125
22:38:26.687899 IP 192.168.20.225.38310 > 239.255.255.250.1900: UDP, length 125
22:38:26.848750 IP 192.168.20.204.5353 > 224.0.0.251.5353: 0 [3q] [1au] PTR (QU)? _companion-link._tcp.local. PTR (QU)? _homekit._tcp.local. TXT (QU)? 01B4303F-1C5E-5DF6-9FFD-8E341557827E._homekit._tcp.local. (131)
22:38:26.849000 IP6 fe80::4e3:79c8:a195:fed1.5353 > ff02::fb.5353: 0 [3q] [1au] PTR (QU)? _companion-link._tcp.local. PTR (QU)? _homekit._tcp.local. TXT (QU)? 01B4303F-1C5E-5DF6-9FFD-8E341557827E._homekit._tcp.local. (131)
22:38:26.983765 IP 192.168.20.225.38310 > 239.255.255.250.1900: UDP, length 125
^C
37 packets captured
41 packets received by filter
0 packets dropped by kernel
 
@panks21

In the adguard UI->Query Log, You can click on the left most question mark(or the question mark in Request Column) and that'll tell you which endpoint was used to resolve that domain.
2021-03-26_22:40:15_1104x213.png
 

I guess you are correct.. The port 53 resolved DNS takes 8ms and on port 853 takes 385ms. Let me remove the DoT and check
 


After monitoring for approx 24 hrs, the results have worsen even further. Any other suggestions. Following is the current DNS setting

Code: 
59.144.144.100
1.0.0.1
9.9.9.9
8.8.4.4
 
Try only one DNS provider both in the Primary , Secondary and check. If it still gives problems , then disable all the blocking lists and let the traffic fow directly , then check the time
 
There is a issue in their repo for this, 'Average processing time' per request shows wrong numbers · Issue #1288 · AdguardTeam/AdGuardHome

If you have some time, Consider trying this, It won't fix the issue but you may get a better idea of what is going wrong.

1. Disable all cache in AdguardHome.yaml
2. Run adguard as, AdGuardHome -v
3. Only use DoT/DoH endpoints in Loadbalance or parallel request mode.

Check the logs and see what happens in a request that has a very high response time. I have shared my logs in the issue I linked above
 
@ishanjain28 Thanks for the update and help. For now I have reimaged the RPI4 and running Adguardhome as container. I am not using the quad9 DNS. I am now settled at 120ms response time for past 24 hours with following upstream DNS servers

Code: 
tls://dns.google
tls://1.1.1.1
59.144.144.100
1.0.0.1

I hope it stays that way. Will report back in a few days
 
Reporting back post 8 days of usage.... Its ranged between 118ms to 132ms.. which is reasonable. This is without quad9 DNS

 
I have these as revolvers

Code: 
tls://1.1.1.1
tls://101.101.101.101
tls://dns-unfiltered.adguard.com
tls://8.8.8.8
tls://dns.comss.one

Its set to parallel requests mode

Rate Limit set to 0

Cache size: 9999999 Bytes (overkill ik)

Min TTL: 3200 seconds
Max TTL: 7200 seconds

Average Processing Time is between 30-50ms (atleast partly thanks to cache and ttl extension i assume). Its running on my PFSense box itself though.
 

Similar threads

itsudd
AdguardHome Processing time
Replies
7
Views
2,135
itsudd
JB701
  • Article Article
Installing AdGuard Home on PFSense
2 3 4 5
Replies
70
Views
76,424
nishantt6969
Top