-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
small random sleep at renewal to avoid load spikes #1656
Comments
Hello Jacob, The user agent
The users of lego as a library will not have this specific user agent. Sorry but I don't know the list of projects that use lego as binary. I think we can implement a randomized delay in the CLI inside the renew command, I will work on it. |
Thanks so much! |
@jsha, do you have a version breakdown of that spiky chart for If the latter number is low, we have a slow adoption rate for updates and it might take time to actually resolve this issue (even with random delay available in v4.8.0). Regarding Lego-as-library users, https://github.com/go-acme/lego/network/dependents list a few popular repositories (measured by stars, each > 1k):
Sadly, this list cannot be sorted by stars (I've groked only the first few pages), and I don't know if it traverses whole dependency trees. However this would be a good start for further research. |
@dmke the users of the library don't have the user agent |
I don't have the version breakdown but I can get it tomorrow. Yep, uptake will take some time - but "the best time to plant a tree was twenty years ago. The second best time is now." :-) |
Indeed, they might use In any case, I'll later prepare a PR with some text snippets and configuration examples about "being a good netizen", to put into the README and/or on the website. |
Not exactly, |
Even better :) |
- split examples into multiple pages - restructure content a bit - flesh out some sections - add a section about load spikes (cf. go-acme#1656)
Here's the distribution of versions seen during the interval from 00:00:00 to 00:00:30. It looks as expected, with the nearly-most-recent version heading the pack:
|
I just add the blog post made by Bitnami about this topic. https://blog.bitnami.com/2022/07/bitnami-lets-encrypt-lego-teams-troubleshooted-bncert-issues.html
I really appreciate the thanks from Bitnami/VMware and the highlight on the power of open-source. |
…elay](go-acme/lego#1656) to the `renew` command, but we don't need this delay at the start because it's not an automated task.
Welcome
How do you use lego?
Other
Detailed Description
Hiya! I'm an engineer at Let's Encrypt. Lately we've been having severe load spikes at 00:00 UTC every day. We've run into similar issues in the past, and historically the issue has been large numbers of users manually configuring their cron jobs to run renewals at exactly midnight every day. It gets worse - because many of these jobs fail due to overload conditions, the next day the load spike may be bigger!
In Certbot the problem is partly solved by packaging - all the major packaging for Certbot arranges for it to run at a random time throughout the day. However, there are still people who manually setup Certbot in crontab, and they often choose 00:00 UTC to run it. So, some years ago Certbot added some code:
certbot/certbot#6391
certbot/certbot#6596
certbot/certbot#6599
When
certbot renew
is run non-interactively, it will sleep a random amount of time up to 8 minutes. This helps spread out the midnight load spike significantly.Right now lego-cli is the top participant in the load spike. During the first 30 seconds after 00:00 UTC today, lego-cli accounted for 33k new-order requests, while the next biggest contributor accounted for only 5.6k new-order requests. For all requests (not just new-order) lego-cli accounted for 173k vs 19k for the next biggest contributor (60% of the total).
Considering all lego-cli traffic to Let's Encrypt, it's very spiky:
So, two questions:
Thanks,
Jacob
The text was updated successfully, but these errors were encountered: