On 6/17/24 11:02, Gavin Brown wrote:
Servers of RDAP data should already have various caching mechanisms
(if not, they are in big trouble…) so the hit to a server is
insignificant.
In my experience, cache hit rates for RDAP is quite low (20-30%), because a
common usage pattern is:
listOfDomains.forEach((domain) => doRDAPQuery(domain));
Therefore you don't get a lot of repeat queries, meaning that you have to
generate fresh responses each time. Therefore substituring an expensive GET for
a cheap HEAD has the potential to be quite helpful.
I don’t understand your point. RDAP objects are relatively long-live. So one
can subscribe to a caching service and have its data cached.
That's one way to implement RDAP but I suspect probably not the most common
one. A much more likely implementation is live generation + a caching reverse
proxy like Squid/Varnish/$CDN, just like every other web app. Those front-end
servers will not keep warm caches, and their caches are probably not shared
between instances, AZs or regions. And many RDAP server operators are required
to invalidate their cache every so often in order to ensure that changes to
registration data become visible within a time dictated by an SLA.
I agree with Gavin here. There are cases where some RDAP objects can be
long lived but most are not. In my experience, the most effective are
application-aware caches like LRUs. Being able to pull from cache and
throw the answer on the wire is as few packets as possible is a benefit
to servers.
I think I misunderstood you when you said "asynchronous", I took that
to mean "in parallel". Obviously an RDAP client cannot do query to the
registrar RDAP server in parallel to the query to the registry RDAP
server, as it needs to the registry response in order to learn the URL
of the registrar server.
But again, the use case you're basing your argument from is that of an
interactive client, where the benefits of my proposal will not be all that
great. That is not the only use case for RDAP.
And the vast bulk of both Whois and RDAP queries come from automation,
not people.
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
