The earlier implementation of dns_agent_thread_func() used getaddrinfo_a() to asynchronously resolve IP addresses, but retrieved the TTL separately using ares_getaddrinfo() in a blocking manner. 
This caused the main thread to spin-wait, reducing overall efficiency when handling multiple DNS requests. 
Since ares_getaddrinfo() can obtain both the IP address and TTL in one call, we plan to replace getaddrinfo_a() entirely and leverage c-ares' ARES_OPT_EVENT_THREAD option to execute ares_getaddrinfo() concurrently.
More fixed detail:https://arraynetworks.atlassian.net/wiki/x/LYA3qw

To evaluate the impact of the asynchronous DNS mechanism on the webagent’s performance, three test scenarios were conducted using different combinations of resolvable and unresolvable hostnames:
Scenario 1: 1000 real (resolvable) hostnames
Scenario 2: 1000 fake (non-resolvable) hostnames
Scenario 3: 500 real + 500 fake hostnames
In Scenario 1, where all hostnames are valid, the execution time is nearly identical for both the original and asynchronous implementations, indicating no significant performance gain in this case.
In Scenario 2, with all hostnames being fake, the original implementation experiences noticeable delays, likely due to the main thread processing DNS queries one at a time. The asynchronous version, however, eliminates this bottleneck by handling queries concurrently.
In Scenario 3, the mixed case, the asynchronous build shows a clear performance advantage. It processes multiple queries in parallel, significantly reducing total execution time, whereas the original build continues to stall on unresolved hostnames.