24 ms·
But the developer is in the best position to decide whether he should fix the code. Perhaps he's just testing something, that will be rewritten later. 30+ secon
by RivieraKid 13y ago
But the developer is in the best position to decide whether he should fix the code. Perhaps he's just testing something, that will be rewritten later. 30+ seconds requests are not always bad.
It has a cost (it takes time to fix it) and value (users won't have to wait). The developer has more information than Google to decide whether cost or value is higher.
- yid 13y agoOut of curiosity, can you describe a situation where 30+ second requests on a large-scale, high-traffic system is acceptable (in the sense that it is better to hold the connection waiting rather than erroring out)? EDIT: long-polling aside, and even then, 30 seconds is a perfectly acceptable limit.
- RivieraKid 13y agoI don't have experiences with large-scale systems, so no. 30+ secs can be useful for smaller projects though.
- papaf 13y agoStreaming music and video? Realtime updates? While I agree that a 30 second limit is to be expected in order to conserve resources, saying long requests aren't needed shows a lack of imagination.
- yid 13y agoRealtime updates (if you're not using Websockets) are usually done with long-polling, for which 30 seconds is perfectly acceptable. Socket.io, for example, uses a default of 20 seconds [1]. Streaming music and certainly video are generally delivered as chunks, with a few chunks per request that don't require long connections [2]. [1] https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Soc... [2] http://en.wikipedia.org/wiki/HTTP_Live_Streaming http://en.wikipedia.org/wiki/HTTP_Live_Streaming