szmarczak / cacheable-lookup

A cacheable dns.lookup(…) that respects TTL :tada:
MIT License
190 stars 29 forks source link

DNS lookup are not cached #54

Closed sarthakgithub closed 2 years ago

sarthakgithub commented 2 years ago

@szmarczak , we are using package - https://www.npmjs.com/package/cacheable-lookup and https://www.npmjs.com/package/@szmarczak/http-timer packages.

Now, when we are hitting domain for the first time , lookup event is getting triggered and lookupListener function is getting called. when we are hitting same domain the next time, caching should take place and 'dns' should get reduced acording to calculation , i.e, -> dns - timings.lookup - timings.socket , but our dns timing is not getting reduced, also, this time our 'lookup' event is not getting fired and lookupListener function is not getting called.

So according to the source code -

timings.lookup = timings.connect; timings.phases.dns = timings.lookup - timings.socket!;

so we are getting high dns time which shouldn't be the case.

Please suggest how we can use both the packages such that we can observe lesser dns time when entry is picking from cache.

Awaiting for a positive response.

renatomariscal commented 2 years ago

@sarthakgithub I am not an expert, but it sounds to be working correctly from your description.

The lookup event means an actual DNS enquire is performed, so looking at the timing of those won't give you an average reduction unless the DNS server is overwhelmed.

It should give you a great reduction on the count of those, as they are just not performed, which sounds to be confirmed by your "'lookup' event is not getting fired".

Am I missing something?

szmarczak commented 2 years ago

https://runkit.com/szmarczak/6216f010c015ea00080b7dbe

[some big number]
0 [or 1]

As you can see it takes some time to get the first response, but the next one is cached. lookup is getting fired but much faster than usually.

https://runkit.com/szmarczak/6216f103768a8c000a2d21a2

Try uncommenting the install call. As you can see, without that - it takes ~15ms as it performs another DNS call. With that included - there's no wait.

szmarczak commented 2 years ago

@sarthakgithub Unless you provide more details on your issue, I see no problem here.