Closed sarthakgithub closed 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?
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.
@sarthakgithub Unless you provide more details on your issue, I see no problem here.
@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.