Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The question I have is why were those lookups a problem in the first place? It's just a metric, is it really important that it's sent one tick later?

As another commented pointed out the "solution" only uses a single IP, even if the resolver returned multiple.

I would not use this in production.



If you're reimplementing DNS lookups with caching in your own code, you are very likely doing something wrong.

The title of the entire story already had me confused, as it suggests you somehow need DNS for UDP. Everything that is presented here is a caching strategy.


> with caching in your own code, you are very likely doing something wrong

In this case it is probably 'using the wrong tool, Node.js'. [0]

> The title of the entire story already had me confused

I needed to read the whole article two times to understand what exactly is going on.

It's really should be titled "Sending UDP Messages a bit faster in Node.js because Node.js by default sucks at invoking getaddrinfo()"

[0] https://youtu.be/v79fYnuVzdI


No sane code in the world should do a DNS lookup on every packet sent. That is absurd.


I haven't read the article yet but the problem I had back then running into UDP with DNS on K8S is that it might consume the UV thread pool and exhausted it.

There is only 4 UV threadpool, and DNS resolution use it. When using service with low ttl or if for wahtever reason bug or something and if node has to resolve DNS every time under highload, it's very quickly consume all of thoese 4 UV thread pool.


The thread pool can be made larger with the environment variable. The author didn't mention they were running into that issue, however.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: