Azure AI Search – Significant Latency Difference Across Client Machines (Same Region & Network)

Hello @Sreshta Talluri ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Even when two clients use the same region, endpoint, index, and REST payload end-to-end latency can still differ because the request path includes multiple layers such as DNS, network transfer, TLS setup and service execution. The latency can occur at different points in the request and response chain that DNS configuration is critical when private endpoints are used.

1. As a first step please confirm whether the difference is consistent or intermittent as this distinction will help narrow the investigation quickly:
   1. If one client is consistently slower, the more likely causes are DNS resolution differences, routing asymmetry, proxy/firewall inspection, or client configuration differences.
   2. If both clients are occasionally slow, then transient network conditions or service-side variability should also remain in scope.
2. Validating DNS resolution and private endpoint behavior As the service is being accessed through a private endpoint, DNS is one of the most important checks.The DNS must be correctly configured so the connection resolves to the private endpoint IP and that public endpoint DNS behavior may need to be overridden for private connectivity to work correctly Please check whether both clients resolve the search endpoint to the same private IP address:

      nslookup <search-service-name>.search.windows.net
   

   Also review whether there are any differences in:
   • DNS forwarders or resolvers
   • private DNS zone linkage
   • cached DNS entries or TTL behavior
   • split-horizon DNS behavior
   If the two machines resolve differently, the requests may be taking different network paths before ever reaching the service.
3. Comparing the network path from both clients If DNS matches, the next priority is to compare the actual route taken from each client. Azure guidance for performance analysis notes that latency can occur during network transfer as well as during service execution, so this step is important before assuming a backend issue Please run a route comparison from both clients to the resolved private IP:

      tracert <resolved-private-ip>
   

   When comparing results, look for:
   • different hop counts
   • unusual detours
   • added latency on one path
   • signs of proxy, VPN, or security inspection devices in the route
   If one client shows a longer or more complex path, that would strongly suggest the latency is occurring at the network layer rather than within AI Search itself.
4. Breaking down client-side timing to isolate where the delay begins Once DNS and route are compared, the next step is to identify whether the delay is occurring during:
   • name resolution
   • TCP connection setup
   • TLS handshake
   • time waiting for the first byte of the response
   A curl timing test is often the fastest way to separate these phases:

      curl -w "
      DNS: %{time_namelookup}
      Connect: %{time_connect}
      TLS: %{time_appconnect}
      TTFB: %{time_starttransfer}
      Total: %{time_total}
      " -o /dev/null -s https://<endpoint>
   

   If DNS, connect, or TLS times differ materially between the two machines, the issue is likely client-side or network-related. If those stages are similar but total time still diverges, service-side telemetry should be checked next.
5. Validating Azure AI Search telemetry to compare service-side execution It is recommended to use Azure Monitor metrics and diagnostic logging to understand query performance and determine whether the issue is occurring within the service or elsewhere in the request path. Diagnostic logging is specifically described as essential for monitoring indexing and query operations, and query monitoring documentation highlights latency, QPS and throttling as the core signals to review. The main telemetry to review is:
   • Search latency
   • Search queries per second (QPS)
   • Throttled queries
   • any indexing activity occurring during the same time window
   If service-side latency remains stable while one client still reports much higher end-to-end time, the variance is likely outside the service.
6. Comparing client environment differences If DNS, routing and service telemetry do not immediately explain the difference, the remaining likely causes are environment-specific client factors such as:
   • explicit or transparent proxy configuration
   • endpoint protection or TLS inspection
   • VPN or split-tunnel behavior
   • OS-level networking behavior
   • differences in connection reuse or pooling
   These factors can add measurable latency even when the service and query are identical. This is especially relevant in private networking scenarios where local enterprise controls may affect only one machine or subnet path.

The following references might be helpful , please check them out

• Analyze Performance - Azure AI Search | Microsoft Learn
• Monitor Queries - Azure AI Search | Microsoft Learn
• Configure Logging - Azure AI Search | Microsoft Learn
• Monitor Your Search Service - Azure AI Search | Microsoft Learn
• Monitoring Data Reference - Azure AI Search | Microsoft Learn
• Create a Private Endpoint for a Secure Connection - Azure AI Search | Microsoft Learn
• Azure Private Endpoint private DNS zone values | Microsoft Learn
• Azure Private Endpoint DNS Integration Scenarios | Microsoft Learn

Please let us know if the response was helpful

Thank you