charm search autocomplete has slow options request times

[Jeff Pihach]

When making an autocomplete request in the browser the actual query response times are ~ 200ms which is acceptable however the initial options request takes anywhere from 400-800ms which makes the AC feel like it's broken for upwards of 1s.

[Aaron Bentley (abentley)]

Wacky. We return as early as possible for an OPTIONS, without hitting DB or anything, while a search hits Elasticsearch. Perhaps the "query response" is coming out of cache, but not OPTIONS.

[Richard Harding (rharding)]

When I checked this the OPTIONS request was 300-400ms and the actual autocomplete suggestions was between 100-200ms. It was crazy. Once that branch lands we can QA and look into it more.

[Abel Deuring (adeuring)]

It seems that these slow response time occurs only after some time of browser inactivity.

Both Rick and myself see that the first OPTIONS request to manage.jujucharms.com may very well need 500msec or more; after this "initial request", Rick sees (from the USA) response times of 130..160msec for the following GET _and_ OPTIONS requests; I see (from Germany) response times of 50..60msec. This time is close to the ping time of 40msec to jaculus.canonical.com, the last machine I see in traceroute that is responding to pings.

Rick and I think that the long response time of the first request is needed to establish a new TLS connection. Difficult to reduce, though perhaps a bit annoying for a first visible response when a user types something into the search field.