Skip to content
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

Improve retrieval efficiency for pending and valid authzs #5764

Closed
jsha opened this issue Oct 29, 2021 · 2 comments
Closed

Improve retrieval efficiency for pending and valid authzs #5764

jsha opened this issue Oct 29, 2021 · 2 comments

Comments

@jsha
Copy link
Contributor

jsha commented Oct 29, 2021

When you create a new order, Boulder first checks the authz2 table to see if there are any pending or valid authzs for the names you asked for, so it can reuse them in the order. Right now this relies on an index (registrationID,identifierType,identifierValue,status,expires). But when the index grows quite large, particularly for accounts with lots of identifiers or lots of authzs, even an index lookup can get expensive.

We can do better: we can have a mapping in some datastore (DB or Redis) from (regID, identifierValue, identifierType) to at most one authz ID. That authz ID would be the "best" available at any given time - a valid authz if one is available, or a pending otherwise, or nothing if there is neither a pending or valid authz. We would update this value when a pending authz is created and when an authz transitions to invalid, valid, or deactivated. We would also need to update it when the authz expires. We could do this reactively at query time - if we find an entry here, look up the authz ID and find it is expired, we would delete the entry. Alternately, we could choose to not delete on expiry. The intuition is that any time we find an expired authz, the very next thing we're likely to do is create a new authz, which will immediately overwrite the existing entry.

We would expire entries out of this datastore with TTLs or partitioning.

@aarongable
Copy link
Contributor

While we obviously want to keep the identifierType around in the main database, I think this quick-lookup "authz cache" could leave it behind: DNSNames cannot look like IPAddresses because their TLD can't start with a digit. So simply storing the identifier should still give sufficient uniqueness.

@aarongable
Copy link
Contributor

This is now duplicated by, and more thoroughly described in, #7715

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants