v4.15.4 performance issue

[tlimoncelli]

CC @das7pad

Describe the bug
Cloudflare performance is much worse in dnscontrol-v4.15.4

@das7pad Could this be a locking problem? I'm

dnscontrol-v4.15.3

real	0m43.916s
user	0m4.547s
sys	0m0.679s

dnscontrol-v4.15.4

Ran for more than 20 minutes.

(Sadly I have to run to catch a train. Maybe this is something stupid I'm doing on my side. Either way, I thought I'd submit this just in case.)

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

DNS Provider

• FILL IN

Additional context
Add any other context about the problem here.

[das7pad]

#3394 should fix this performance regression. Sorry!

[tlimoncelli]

Weird. It fixed it for my on the command line but when I upgraded our internal Github action to use it, the GHA runs forever.

Could be pilot error (my fault). I don't have time to investigate today but I'll get to it when I can.

[Firefishy]

Cloudflare seems to take much longer because it seems to change all records at Cloudflare from an unset TTL (TTL=1) to TTL=300 in v4.15.4 and v4.15.5.

[tlimoncelli]

Cloudflare seems to take much longer because it seems to change all records at Cloudflare from an unset TTL (TTL=1) to TTL=300 in v4.15.4 and v4.15.5.

I think we have two issues:

1. Not treating TTL=300 as magic has had some unexpected, but not serious, side effects. The magic "TTL=1" is only valid for A/AAAA/CNAME records with "proxy on". However we were changing TTL 300 -> 1 for all records. I'm going to call the old behavior a bug (for example, my CAA records were all TTL=1), and the new behavior (CAA records 1->300) to be fixing the bug.

2. Cloudflare speed. Where do you see the TTL behavior change affect integration run-time? (I may be confused)

[Firefishy]

Cloudflare seems to take much longer because it seems to change all records at Cloudflare from an unset TTL (TTL=1) to TTL=300 in v4.15.4 and v4.15.5.

I think we have two issues:

1. Not treating TTL=300 as magic has had some unexpected, but not serious, side effects. The magic "TTL=1" is only valid for A/AAAA/CNAME records with "proxy on". However we were changing TTL 300 -> 1 for all records. I'm going to call the old behavior a bug (for example, my CAA records were all TTL=1), and the new behavior (CAA records 1->300) to be fixing the bug.
2. Cloudflare speed. Where do you see the TTL behavior change affect integration run-time? (I may be confused)

1. The first dnscontrol run after upgrade to >=4.15.4 took much longer because it updated all our records that didn't have a TTL set (Cloudflare "Auto" TTL) to a static 5min TTL at Cloudflare.

[tlimoncelli]

Ah, yes, the next "push" will take a lot longer.