5 ms·

I appreciate when features are in test phase that it makes sense to keep it simple. But this is in production, and there are many dead-simple solutions that do

I appreciate when features are in test phase that it makes sense to keep it simple. But this is in production, and there are many dead-simple solutions that do this efficiently, long polling, SSE, etc. This is Google after all.

Raidion 7y ago
To implement this, you have to have a developer who is doing something else switch to this, get up to speed, and make a change. This involves risk and opportunity cost. The question for enterprise software development isn't "Will this make this thing better?", but "Is making this change more valuable than the other things on the priority list?"
- matt_oriordan 7y ago
  Sure, but I'm never suggested front-end developers should build new tech every time they want a new feature. But there are solutions to do things better now, so it seems odd to ignore that. It's a bit like saying React/Angular/Vue/any other frontend framework won't make things tangibly better, so why bother. Or optimising page size won't make things better, so why bother. Google actively invests in telling everyone else to optimize their websites and even prioritizes fast sites over slow sites (https://developers.google.com/speed https://developers.google.com/speed). Why shouldn't they care about their performance too?
  - askmike 7y ago
    This isn't just a frontend optimization that can be applied in isolation by a good dev. With WS or SSE there now needs to be server written & supported to push this data over. On top of all the networking issues that come with these streaming protocols. > Why shouldn't they care about their performance too? They definitely do this for everything they push out that runs on billions of devices for people all over the world. How many people use Google to keep track of the live score of "the Laver Cup tennis championship in Australia?" I'd be surprised if that's more than 100. But Google has these numbers, and based on that they've chosen not to optimize this.
    - nostrademons 7y ago
      There's also the issue of optimizing for users of sports fans but pessimizing for the general population. Say that they do this "right" and include a real-time websockets client that has all the proper reconnect logic, uses a minified protocol, has a proper real-time stack on the backend with all the appropriate DDoS protection, encryption, CORS, etc. All the client logic is extra bytes that need to be shipped on every search request. Or they could split the bundle and lazy-load it, which is still extra bytes, but fewer of them, and adds complexity. The server code needs to be audited for security; one compromised frontend server and the damage to Google is already more than the entire value of the feature. One black-swan websearch outage (caused, say, by a misconfiguration leading to the load balancers getting slammed by websocket connections, or a misconfiguration causing the DDoS servers to think websearch is actually undergoing a DDoS when it's just normal websocket traffic) is already more than the entire value of the feature. The bar for simplicity and reliability has to be pretty high for a feature that's going to be used by 0.0001% of users, because if there are any negative effects at all on mainstream websearch traffic, that feature should never have been launched.
      - matt_oriordan 7y ago
        I agree complexity should be avoided. But I don't really follow the logic that if every feature can break security, reliability, etc. you should never change anything or progress. Google is doubling down on these features as you can see at https://www.seroundtable.com/google-pin-live-scores-28261.html https://www.seroundtable.com/google-pin-live-scores-28261.ht.... If they're continuing to invest in adding more realtime features, and penalising sites in search results that don't optimise their websites https://www.sitecenter.com/insights/141-google-introduces-penalty-for-slow-websites.htm https://www.sitecenter.com/insights/141-google-introduces-pe..., then I think they should apply that same logic to their own site IMHO.
        summerlight 7y ago
        Probably that's why Google is trying to improve network protocols (QUIC, HTTP/3) rather than relying on one-off optimizations described in the article.
  - riknos314 7y ago
    Speaking of optimization, keep in mind this shows up at the top of the results page. Any of the "more optimal" streaming solutions would likely require more JS on the page, and thus make the page as a whole heavier and load slower, which is actually worse for Google as a whole. Looking at just this feature in isolation misses the real-world problems immediately surrounding it.
deleted 7y ago
[deleted]
cbhl 7y ago
Those solutions are not dead-simple at scale: they consume resources (such as file handles) on the server and they have to be supported by middle-boxes (such as proxies and reverse-proxies). Google gets to see the actual error rates when these solutions are deployed in production. If you want traffic to get through to end-users, then it has to look like what network administrators expect to get to the long tail. The end result: QUIC is encapsulated in UDP, DNS-over-HTTPS, and MPEG-DASH live streaming (making streaming video look like HTTP, and making a new request every few seconds). If you are not at Google scale, please, yes, use the newer, simpler technology.
- wahern 7y ago
  > MPEG-DASH live streaming IMO that was more dictated by server-side complexity. A multimedia streaming server, especially for live video, that is optimized end-to-end for robustness and efficiency can be a very complex beast. Streaming transcoding, metadata injection, buffering, etc are difficult on their own. Doing them together in a unified fashioned is especially difficult. Solutions like GStreamer that abstract this away and make it conceptually simple are also extremely inefficient at scale. (Take it from someone who wrote an entire end-to-end solution that could do M:N codec, format, and transport transcoding, per-user streaming ad injection, and a bunch of other stuff. I could do 5k+ live audio streams, each with unique ad injection/splicing, with most of the pipeline occurring on a single E3 Xeon core--the socket writes to 5,000 clients from a single thread and the resulting ethernet interrupts that caused that CPU to max out. Reusing solutions like GStreamer or FFmpeg directly in your pipeline you'd be extremely lucky to get 1/10 of that, and more likely 1/100 at best.) MPEG-DASH permits the incoming media processor to simply dump a bunch of files to disk. The client facing service can then serve those up however it wishes--it can be completely dumb or incredibly smart, but importantly both halves can evolve on their own. You could do codec and rate transcoding as a third, middle component. And you could break these components down even further, as "everything is a file" is the most basic IPC interface we have. This makes iterative development much easier. IME, MPEG-DASH is pretty much what you'd get if you began with stodgy old (relatively) commercial broadcast equipment using nasty broadcast framing standards and organically built a streaming pipeline from scratch, without ever having the benefit/burden of knowing how to do performant streaming server development, or even how existing solutions worked. The multiple files non-sense was never necessary for client compatibility or network filter bypassing. Apple had solved that with RTSP-over-HTTP tunneling years prior, as did Flash with its clunkier RTMP solutions later.

Raidion 7y ago

To implement this, you have to have a developer who is doing something else switch to this, get up to speed, and make a change. This involves risk and opportunity cost. The question for enterprise software development isn't "Will this make this thing better?", but "Is making this change more valuable than the other things on the priority list?"

matt_oriordan 7y ago
Sure, but I'm never suggested front-end developers should build new tech every time they want a new feature. But there are solutions to do things better now, so it seems odd to ignore that. It's a bit like saying React/Angular/Vue/any other frontend framework won't make things tangibly better, so why bother. Or optimising page size won't make things better, so why bother. Google actively invests in telling everyone else to optimize their websites and even prioritizes fast sites over slow sites (https://developers.google.com/speed https://developers.google.com/speed). Why shouldn't they care about their performance too?
- askmike 7y ago
  This isn't just a frontend optimization that can be applied in isolation by a good dev. With WS or SSE there now needs to be server written & supported to push this data over. On top of all the networking issues that come with these streaming protocols. > Why shouldn't they care about their performance too? They definitely do this for everything they push out that runs on billions of devices for people all over the world. How many people use Google to keep track of the live score of "the Laver Cup tennis championship in Australia?" I'd be surprised if that's more than 100. But Google has these numbers, and based on that they've chosen not to optimize this.
  - nostrademons 7y ago
    There's also the issue of optimizing for users of sports fans but pessimizing for the general population. Say that they do this "right" and include a real-time websockets client that has all the proper reconnect logic, uses a minified protocol, has a proper real-time stack on the backend with all the appropriate DDoS protection, encryption, CORS, etc. All the client logic is extra bytes that need to be shipped on every search request. Or they could split the bundle and lazy-load it, which is still extra bytes, but fewer of them, and adds complexity. The server code needs to be audited for security; one compromised frontend server and the damage to Google is already more than the entire value of the feature. One black-swan websearch outage (caused, say, by a misconfiguration leading to the load balancers getting slammed by websocket connections, or a misconfiguration causing the DDoS servers to think websearch is actually undergoing a DDoS when it's just normal websocket traffic) is already more than the entire value of the feature. The bar for simplicity and reliability has to be pretty high for a feature that's going to be used by 0.0001% of users, because if there are any negative effects at all on mainstream websearch traffic, that feature should never have been launched.
    - matt_oriordan 7y ago
      I agree complexity should be avoided. But I don't really follow the logic that if every feature can break security, reliability, etc. you should never change anything or progress. Google is doubling down on these features as you can see at https://www.seroundtable.com/google-pin-live-scores-28261.html https://www.seroundtable.com/google-pin-live-scores-28261.ht.... If they're continuing to invest in adding more realtime features, and penalising sites in search results that don't optimise their websites https://www.sitecenter.com/insights/141-google-introduces-penalty-for-slow-websites.htm https://www.sitecenter.com/insights/141-google-introduces-pe..., then I think they should apply that same logic to their own site IMHO.
      - summerlight 7y ago
        Probably that's why Google is trying to improve network protocols (QUIC, HTTP/3) rather than relying on one-off optimizations described in the article.
- riknos314 7y ago
  Speaking of optimization, keep in mind this shows up at the top of the results page. Any of the "more optimal" streaming solutions would likely require more JS on the page, and thus make the page as a whole heavier and load slower, which is actually worse for Google as a whole. Looking at just this feature in isolation misses the real-world problems immediately surrounding it.

deleted 7y ago

[deleted]

cbhl 7y ago

Those solutions are not dead-simple at scale: they consume resources (such as file handles) on the server and they have to be supported by middle-boxes (such as proxies and reverse-proxies). Google gets to see the actual error rates when these solutions are deployed in production. If you want traffic to get through to end-users, then it has to look like what network administrators expect to get to the long tail. The end result: QUIC is encapsulated in UDP, DNS-over-HTTPS, and MPEG-DASH live streaming (making streaming video look like HTTP, and making a new request every few seconds). If you are not at Google scale, please, yes, use the newer, simpler technology.

wahern 7y ago
> MPEG-DASH live streaming IMO that was more dictated by server-side complexity. A multimedia streaming server, especially for live video, that is optimized end-to-end for robustness and efficiency can be a very complex beast. Streaming transcoding, metadata injection, buffering, etc are difficult on their own. Doing them together in a unified fashioned is especially difficult. Solutions like GStreamer that abstract this away and make it conceptually simple are also extremely inefficient at scale. (Take it from someone who wrote an entire end-to-end solution that could do M:N codec, format, and transport transcoding, per-user streaming ad injection, and a bunch of other stuff. I could do 5k+ live audio streams, each with unique ad injection/splicing, with most of the pipeline occurring on a single E3 Xeon core--the socket writes to 5,000 clients from a single thread and the resulting ethernet interrupts that caused that CPU to max out. Reusing solutions like GStreamer or FFmpeg directly in your pipeline you'd be extremely lucky to get 1/10 of that, and more likely 1/100 at best.) MPEG-DASH permits the incoming media processor to simply dump a bunch of files to disk. The client facing service can then serve those up however it wishes--it can be completely dumb or incredibly smart, but importantly both halves can evolve on their own. You could do codec and rate transcoding as a third, middle component. And you could break these components down even further, as "everything is a file" is the most basic IPC interface we have. This makes iterative development much easier. IME, MPEG-DASH is pretty much what you'd get if you began with stodgy old (relatively) commercial broadcast equipment using nasty broadcast framing standards and organically built a streaming pipeline from scratch, without ever having the benefit/burden of knowing how to do performant streaming server development, or even how existing solutions worked. The multiple files non-sense was never necessary for client compatibility or network filter bypassing. Apple had solved that with RTSP-over-HTTP tunneling years prior, as did Flash with its clunkier RTMP solutions later.