|
|
|
|
|
by jfim
4858 days ago
|
|
It's probably the wall time for the various backend services to respond to the query. If you think about it, a Google search result is actually many things; it has results from various sources, such as the web, images, videos, news, social signals from G+, etc. All of those are different services that are aggregated to build your result page. Since all of those queries are fired at the same time, the only metric that matters at the end is the wall time, not the CPU time used during the query. I also seriously doubt that the servers that handle the Google front page can only do one query at a time; at the very least, they're multithreaded, but probably concurrent. It probably works as below: 1. Parse query
2. Send query to backend servers
3. Wait until all backends replied or at most 250ms (or some other timeout)
4. Assemble the result page and ship it back to the client While the server is idling for the backends to reply, it probably processes other queries; it wouldn't make sense to waste that much CPU power. Finally, your example says 0.12s (a random query on my end gave a response time of 0.69s), which is 120ms (or 690ms for mine), which is more than twice 30ms. |
|