Very slow HTTPS (even to hosts in the same network)

[nguadagno]

Is it a duplicate question?
Couldn't find anything

Describe the bug
HTTP(S) requests take a tremendous long time.

To Reproduce
Steps to reproduce the behavior:

1. Add a new monitor
2. Wait a few moments for the data to come in

Expected behavior
Pings in the same local network should not be over 500 ms, but they are.

Info
Uptime Kuma Version: 1.7.3
Using Docker?: Yes
Docker Version: Docker version 20.10.7, build 20.10.7-0ubuntu1~20.04.2
OS: Ubuntu server 20.04 LTS kernel 5.4.0-88-generic
Browser: Firefox 93.0

Docker logs:

Monitor #3 : Successful Response: 70 ms | Interval: 60 seconds | Type: http
Monitor #1 : Successful Response: 164 ms | Interval: 60 seconds | Type: http
Monitor #2 : Successful Response: 710 ms | Interval: 60 seconds | Type: http
Monitor #4 : Successful Response: 46 ms | Interval: 60 seconds | Type: ping
Monitor #3 : Successful Response: 22 ms | Interval: 60 seconds | Type: http
Monitor #1 : Successful Response: 163 ms | Interval: 60 seconds | Type: http
Monitor #2 : Successful Response: 566 ms | Interval: 60 seconds | Type: http
Monitor #5 : Successful Response: 0 ms | Interval: 180 seconds | Type: ping
Monitor #4 : Successful Response: 45 ms | Interval: 60 seconds | Type: ping
Monitor #3 : Successful Response: 21 ms | Interval: 60 seconds | Type: http
Monitor #1 : Successful Response: 144 ms | Interval: 60 seconds | Type: http
Monitor #2 ':Successful Response: 572 ms | Interval: 60 seconds | Type: http
Monitor #4 : Successful Response: 50 ms | Interval: 60 seconds | Type: ping
Monitor #3 :Successful Response: 18 ms | Interval: 60 seconds | Type: http

Monitor #2 is going a public DNS record, but the host is on the same virtual machine and all my other machines in the same network take <1ms to get to it.
Monitor #1 is a remote host that normally has around ~50ms ping from my network.
Monitor #3 is also a public DNS record that points to my public IP and, again, its <1ms for all the other hosts, but a lot higher from Kuma.

It's not really a problem since it works fine, but I'd like them to be quicker, so that I can spot problems quicker. I'm guessing this is because Kuma doesn't use any DNS caching (or the local adguard server) but goes throught the NS every time. Is there any way to improve this?

[louislam]

DNS cache was discussed before, I cannot find the thread.

I remember that, the conclusion is that Node.js do not provide dns cache function. It is not easy to add this on my own.

A workaround: specify --dns "your local server" in the docker run command.

[chengunm]

I konwed it, thank you wery much.

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "louislam/uptime-kuma" ***@***.***&gt;; 发送时间:&nbsp;2021年10月10日(星期天) 中午11:46 ***@***.***&gt;; ***@***.***&gt;; 主题:&nbsp;Re: [louislam/uptime-kuma] Very slow HTTPS (even to hosts in the same network) (#628) DNS cache was discussed before, I cannot find the thread. I remember that, the conclusion is that Node.js do not provide dns cache function. It is not easy to add this on my own. A workaround: specify --dns "your local server" in the docker run command. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[nguadagno]

@louislam I've tried that but nothing seems to improve.

[gaby]

@louislam Thoughts on this library: https://www.npmjs.com/package/cacheable-lookup
They have full dns lookup examples here: https://httptoolkit.tech/blog/configuring-nodejs-dns/

There's also an axios compatible one here: https://npmjs.com/package/axios-cached-dns-resolve

[nguadagno]

Somehow it managed to get even worse...

Monitor #4 : Successful Response: 46 ms | Interval: 60 seconds | Type: ping
Monitor #2 : Successful Response: 19849 ms | Interval: 60 seconds | Type: http
Monitor #3 : Successful Response: 28 ms | Interval: 60 seconds | Type: http
Monitor #4 : Successful Response: 29 ms | Interval: 60 seconds | Type: ping
Monitor #1 : Successful Response: 12723 ms | Interval: 60 seconds | Type: http
Monitor #2 : Successful Response: 33656 ms | Interval: 60 seconds | Type: http
Monitor #3 : Successful Response: 28 ms | Interval: 60 seconds | Type: http
Monitor #4 : Successful Response: 29 ms | Interval: 60 seconds | Type: ping
Monitor #1 : Successful Response: 13356 ms | Interval: 60 seconds | Type: http

For now I'll go back to some other uptime monitor, Kuma is not very usable in my case as it is right now. I'll keep checking in on it since I really love the idea and I'll try again in a few months. I'm very sorry :/

[chakflying]

@louislam Thoughts on this library: https://www.npmjs.com/package/cacheable-lookup They have full dns lookup examples here: https://httptoolkit.tech/blog/configuring-nodejs-dns/

There's also an axios compatible one here: https://npmjs.com/package/axios-cached-dns-resolve

Wow this is exactly what we need! The axios one is in ESM tho, I'm not sure if we can use it.

[louislam]

Is the TTL of that record too short?
I believe your local dns server should cache the record for you.

And also make sure you are not using the alpine tag.

[gaby]

It seems like nodejs natively suffers from DNS caching issues. There's a huge discussion about it here: nodejs/node#8436

Suggested solutions are:

• https://www.npmjs.com/package/dns-lookup-cache
• https://www.npmjs.com/package/dnscache

[nguadagno]

Is the TTL of that record too short? I believe your local dns server should cache the record for you.

TTL is 300 for some of the records and 150 for others, it's longer than the interval of the monitors.

And also make sure you are not using the alpine tag.

I'm using the :1 tag, as listed in the README.

[CristianT]

I think this should be moved back to a bug since there is something messed up with the name resolution.
I setup various monitors an name resolution seems to take 5s, or 10s to 12s

If I monitor https://google.com reponse times are regularly between 10400ms and 10600ms.
To discard SSL, response time in http://www.testingmcafeesites.com/ are from 10500ms to 10800ms.
My local router http site using ip address takes from 500ms to 700ms to check
My local grafana healthcheck endpoint https://grafana.mydomain.local/api/health consistently replies between 5010ms and 5015ms, but sometimes it takes 10100ms

One particularity of my system is that I'm running Adguard to filter ads and malicious site, but the response is very fast, plus I have rewritten mydomain.local and it returns a local IP within 0.02ms, and other sites are returned within 26ms, google is even faster.

Running version 1.11.4 in a docker container (louislam/uptime-kuma:1)

[CristianT]

Here is an update:
I installed dnsutils in the uptime-kuma container and the manual name resolution works fine in time and value, but it states the following message:

;; reply from unexpected source: 172.17.0.1#53, expected 192.168.3.11#53

where 172.17.0.x is my docker network and 192.168.3.x is my home LAN. The problem is this adguard instance is running in a container in the same docker host.

I changed the host DNS to 1.1.1.1 and the times are as expected.

I changed it again to an adguard instance outside docker but in my network and times are also as expected.

Aparently I'm not only one with tha issue:
https://forums.docker.com/t/dns-issues-with-local-resolver-and-containers-on-the-same-host/102319/8

The thing is that all the containers I have running in this instance work correctly, the only one with issues that I know is uptime kuma. So in my opinion there are 2 issues, one is the 'unexpected source' message from the docker setup, and the other is that uptime kuma is maybe too strict in the dns queries origin (not sure if on purpose or by chance).

[Saibamen]

Fixed in axios-cached-dns-resolve
tcollinsworth/axios-cached-dns-resolve#27