3 ms·

You are still describing a situation where a client connects directly to a server. At Google, those client connections are probably kept open at a load balance

You are still describing a situation where a client connects directly to a server. At Google, those client connections are probably kept open at a load balancer. The load balancer has its own connections to servers on the other side, and those will be as short-lived as possible, so that the server is available to service the next request the lb sends its way. If you start talking about server-side push technologies, you are keeping a long-lived connection open from the server, through the load balancer, to the client. That will affect the dynamics of the load balancing - it's not as simple as round-robin or random distribution that short-lived requests allow. Consider, for example, a server that becomes overloaded. With short-lived requests you can just add more hosts to the LB pool. With long-lived requests you might need to start thinking about migrating connections, or forcefully terminating some connections if the server hits some kind of load threshold, as well as adding hosts. It's not impossible, it just makes it more complicated and less reliable, which is not what you want for something that just updates a score. As others have pointed out, it's probably just fetching a static file that gets updated periodically.

nostrademons 7y ago
It's actually worse than that: IIRC (this is 10 years old), traffic to Google passes through a custom DNS resolver that geolocates the lowest-latency active datacenter; a load balancer; 2 levels of reverse proxies; DDoS protection; a bastion server that lets SRE quickly kill non-critical traffic if it threatens the stability of websearch; the webserver; numerous application servers (for core websearch this could be tens of thousands per request, but for a feature like this it's probably just one); and the storage layer. With various push technologies, all of these need to be made aware of the need for a server push, and modified to handle potentially long-running connections that receive events at the data-source's command rather than at the user's request. With polling, you write the new data into the data source once and then the infrastructure just picks it up periodically. Websockets etc. are great technologies if you can handle all traffic on a single box; I use them extensively for my startup. They are a terrible technology at scale. If you want to run websockets at scale, I would actually recommend pulling all the real-time features into a side-channel that's updated via RPC when a relevant event happens and listens directly on the Internet, and then making that as lightweight as possible so that it can scale vertically and as non-critical as possible so that users don't care if it goes down momentarily. If your users don't really care about up-to-the-second information (as with sports scores), just don't do it, and use polling instead.

nostrademons 7y ago

It's actually worse than that: IIRC (this is 10 years old), traffic to Google passes through a custom DNS resolver that geolocates the lowest-latency active datacenter; a load balancer; 2 levels of reverse proxies; DDoS protection; a bastion server that lets SRE quickly kill non-critical traffic if it threatens the stability of websearch; the webserver; numerous application servers (for core websearch this could be tens of thousands per request, but for a feature like this it's probably just one); and the storage layer. With various push technologies, all of these need to be made aware of the need for a server push, and modified to handle potentially long-running connections that receive events at the data-source's command rather than at the user's request. With polling, you write the new data into the data source once and then the infrastructure just picks it up periodically. Websockets etc. are great technologies if you can handle all traffic on a single box; I use them extensively for my startup. They are a terrible technology at scale. If you want to run websockets at scale, I would actually recommend pulling all the real-time features into a side-channel that's updated via RPC when a relevant event happens and listens directly on the Internet, and then making that as lightweight as possible so that it can scale vertically and as non-critical as possible so that users don't care if it goes down momentarily. If your users don't really care about up-to-the-second information (as with sports scores), just don't do it, and use polling instead.