3 ms·

It's a great write-up indeed. It's just unfortunate that anything that requires people to do more than "switch a toggle" on Nginx configs will probably not see

It's a great write-up indeed. It's just unfortunate that anything that requires people to do more than "switch a toggle" on Nginx configs will probably not see huge adoption without significant advocacy effort. The truth is that most people do not care (and they're probably right, as they're not heavily dependant on performance). For the past year or so I've started thinking most OSS maintainers should just pick bolder defaults so we can push the web forward more easily.

dspillett 3y ago
> The truth is that most people do not care (and they're probably right, as they're not heavily dependant on performance). This. For all simple cases it doesn't matter. For many not-so-simple cases the buffering is an advantage – it might impose an imperceptible delay on receiving the first data back from the initial request but make that request overall more efficient without significantly affecting anything else. This is why it has become the default in most cases. Only if your page/app is fairly complex (by necessity or by bad design) do you even need to think about buffering being a problem. > so we can push the web forward Not buffering at all is a step backwards in many instances. By all means make this the default in your setup instructions (or docker images etc) for your app/site, but it shouldn't be the default for, say, nginx packages in distros that affect a great many other projects. What this is doing is selective buffering anyway: the buffer is still there, but it is being explicitly flushed at key points. Sometimes this is circumvented by parts further down the chain which you can't control in your code, hence they change the buffering behaviour in nginx. This could be even further beyond your control, perhaps imposed by some proxy that your users sit behind, so keep in mind that this trick does not universally work. One trick I've used for internal utilities (that is a bad idea for more public systems) is to throw out a string of difficult-to-compress content in a comment before flushing. This breaks through small buffers elsewhere in the chain without needing to reconfigure the relevant parts, trading a bit of bandwidth for an apparent latency gain. It is useful for utility scripts that return a lot of data that is then presented in a fancy JS table or graph, send the initial page layout with a holding area saying “loading…”, flush, then send the data. This saves the extra request to get the data while letting the initial UI render while you wait.
vsareto 3y ago
>It's a great write-up indeed. It's just unfortunate that anything that requires people to do more than "switch a toggle" on Nginx configs will probably not see huge adoption without significant advocacy effort. My guess is debugging this would be more complicated than other approaches. It's very nice they got around slow backend queries, but I wonder if this same level of effort could be applied to fix that problem too.

dspillett 3y ago

> The truth is that most people do not care (and they're probably right, as they're not heavily dependant on performance). This. For all simple cases it doesn't matter. For many not-so-simple cases the buffering is an advantage – it might impose an imperceptible delay on receiving the first data back from the initial request but make that request overall more efficient without significantly affecting anything else. This is why it has become the default in most cases. Only if your page/app is fairly complex (by necessity or by bad design) do you even need to think about buffering being a problem. > so we can push the web forward Not buffering at all is a step backwards in many instances. By all means make this the default in your setup instructions (or docker images etc) for your app/site, but it shouldn't be the default for, say, nginx packages in distros that affect a great many other projects. What this is doing is selective buffering anyway: the buffer is still there, but it is being explicitly flushed at key points. Sometimes this is circumvented by parts further down the chain which you can't control in your code, hence they change the buffering behaviour in nginx. This could be even further beyond your control, perhaps imposed by some proxy that your users sit behind, so keep in mind that this trick does not universally work. One trick I've used for internal utilities (that is a bad idea for more public systems) is to throw out a string of difficult-to-compress content in a comment before flushing. This breaks through small buffers elsewhere in the chain without needing to reconfigure the relevant parts, trading a bit of bandwidth for an apparent latency gain. It is useful for utility scripts that return a lot of data that is then presented in a fancy JS table or graph, send the initial page layout with a holding area saying “loading…”, flush, then send the data. This saves the extra request to get the data while letting the initial UI render while you wait.

vsareto 3y ago

>It's a great write-up indeed. It's just unfortunate that anything that requires people to do more than "switch a toggle" on Nginx configs will probably not see huge adoption without significant advocacy effort. My guess is debugging this would be more complicated than other approaches. It's very nice they got around slow backend queries, but I wonder if this same level of effort could be applied to fix that problem too.