3 ms·

> There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms. This is a wishful thinking. You can't exp

> There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms. This is a wishful thinking. You can't expect consistent 10ms (or even 100ms) response times from network-driven autocomplete. Nevermind a fixed speed of light (which already makes 10ms figure impossible for transatlantic users), you will have to account for all kinds of temporary bottlenecks in network. DNS can take a lot longer than 10ms, and many hosts use short DNS TTL by design. There are some totalitarian countries (Belarus, Great Britain etc.) that use DNS-based website blocking — each time you send a DNS request, it will have to be compared against a bunch of censorship lists. Then there is an ISP throttling/AQM, that will add small delays to each SYN packet... As result, if your autocomplete responds in under 10ms during local testing, it may take between 100ms and 900ms for most of your users.

jrockway 6y ago
Yeah there's the network round trip and that is going to be the bulk of the time. You have to serve interactive apps from servers that are close to your users. DNS, even when censored by the government, should be cached by the client for the TTL. And, for interactive apps, you should keep the TCP connection open between requests. (Not really sure what the browser state of the art is here, but the idea behind HTTP/3 is to skip TCP entirely, and let the server control how long it remembers the state necessary to keep the session alive. One autocomplete request should be one UDP packet.) I'll also point out that networks aren't very good. For example, I have a RTT of 50ms to Chicago, but the speed-of-light round trip between New York and London is 36ms. (For Chicago, it's 8ms!) At least on my setup, the vast majority of the time is spent waiting for a DOCSIS timeslot. Once my packet gets to the internet, it's pretty fast. Remember, people are playing real-time shooting games over the Internet. If they can make that smooth, you can make your autocomplete smooth.

jrockway 6y ago

Yeah there's the network round trip and that is going to be the bulk of the time. You have to serve interactive apps from servers that are close to your users. DNS, even when censored by the government, should be cached by the client for the TTL. And, for interactive apps, you should keep the TCP connection open between requests. (Not really sure what the browser state of the art is here, but the idea behind HTTP/3 is to skip TCP entirely, and let the server control how long it remembers the state necessary to keep the session alive. One autocomplete request should be one UDP packet.) I'll also point out that networks aren't very good. For example, I have a RTT of 50ms to Chicago, but the speed-of-light round trip between New York and London is 36ms. (For Chicago, it's 8ms!) At least on my setup, the vast majority of the time is spent waiting for a DOCSIS timeslot. Once my packet gets to the internet, it's pretty fast. Remember, people are playing real-time shooting games over the Internet. If they can make that smooth, you can make your autocomplete smooth.