What latency gets added? Presumably on cache miss they already need to look up "whats the origin for www.example.com" and get info about it. This is just a handful of bytes in that record.
What latency gets added? Presumably on cache miss they already need to look up "whats the origin for www.example.com" and get info about it. This is just a handful of bytes in that record.
I assume they are referring to looking up the first guess to use in their local DB - all new connections get that even those for which the previous simple default would be optimal. If that lookup is hitting storage or going over their local network (or both: hitting storage on another node) rather than the result coming from local RAM, then this might be measurable. Even then, the cost of adding a ms or few to every connection might be much lower than the saving from the reduced round trips. To be worse overall the added latency for this lookup would need to be about 55ms (assuming 150ms saved on each round-trip that would have happened but didn't have to).
If the new for-every-request latency is noticeable above the noise floor at all then they could be really tricksy and make two connection attempts, one immediately with the default guess and one with the looked up value, and as soon as the first connection succeeds abandon the other. In fact if the majority of the connections needing a retry use the same method, so there are two covering almost all cases, you could remove the lookup and just send out two connection attempts, one with each of those two methods. I very much doubt this would be worth the effort, and it would add load elsewhere that would need to be accounted for in judging the value of the optimisation.
They have to check from their data store on the algo they scavenged for the clients, thats the whole idea about being correct instead of making a guess.