Earlier quoted context omitted.
Is it now? nginx seems to have pretty normal behaviour here, so the core issue is write-polling buffers on linux rather than nginx itself. It seems to me nginx was the messenger of sorts, but the issue doesn't really pertain to nginx. In a nearby comment, LoSboccacc notes that they've hit that issue [removed: on S3].
It sounded to me like LoSboccacc's solution was to serve files from S3, not that they experienced the same issue on S3.
The curious case of slow downloads
21–30 of 57 posts
Re: The curious case of slow downloads
#22Earlier quoted context omitted.
The TCP layer is already perfectly capable of detecting if a connection has failed. NGINX wanted to do something extra, and did it incorrectly.
> NGINX wanted to do something extra, and did it incorrectly. Having a timeout on a poll (or select) is not "something extra". it's something entirely normal and necessary for any non-trivial software, especially public-facing ones.
Re: The curious case of slow downloads
#23Related story time: At university, we ran a local quakeworld server (yes, this was in the stone age XD). And I wanted to write a tool to allow users to control to server. It would listen on a network port and pipe its input into the quakeworld server running as a child subprocess. Sounds simple enough, right? Disregarding accept(2)ing connections,etc... it's just going to sit in an endless loop, select(2) on the sock…
Re: The curious case of slow downloads
#24Re: The curious case of slow downloads
#25I'm looking at you Arbor.
Re: The curious case of slow downloads
#26Earlier quoted context omitted.
The TCP layer is already perfectly capable of detecting if a connection has failed. NGINX wanted to do something extra, and did it incorrectly.
> NGINX wanted to do something extra, and did it incorrectly. Having a timeout on a poll (or select) is not "something extra". it's something entirely normal and necessary for any non-trivial software, especially public-facing ones.
Re: The curious case of slow downloads
#27Earlier quoted context omitted.
> NGINX wanted to do something extra, and did it incorrectly. Having a timeout on a poll (or select) is not "something extra". it's something entirely normal and necessary for any non-trivial software, especially public-facing ones.
What? They wanted a timeout on how long it takes X bytes to send on an active TCP connection. That has nothing to do with poll/select timeouts.
nginx called send(file), then polled the socket for write with the timeout, closing the connection if the timeout was hit. It has everything to do with poll/select timeouts, and especially with Linux letting poll hit timeouts when waiting on effectively writable sockets.
Re: The curious case of slow downloads
#28Earlier quoted context omitted.
> NGINX wanted to do something extra, and did it incorrectly. Having a timeout on a poll (or select) is not "something extra". it's something entirely normal and necessary for any non-trivial software, especially public-facing ones.
.. and the correct way to do this is SO_SNDTIMEO.
> [SO_RCVTIMEO and SO_SNDTIMEO] only have effect for system calls that perform socket I/O (e.g., read(2), recvmsg(2), send(2), sendmsg(2)); timeouts have no effect for select(2), poll(2), epoll_wait(2), and so on.
And from my understanding would have the same effect as a timeout on select/poll, so it's not the correct way to do anything.
Re: The curious case of slow downloads
#29I guess dropping very slow connections are also kind of protection against DoS or DDOS attacks, where attacker can drain resources.
Slow requests (like slowloris) were much more effective.
Re: The curious case of slow downloads
#30This is why open source (and controlling your whole stack) matters in big business. For example, Microsoft may be changing their image, but their core software is closed source. may be great, but can you pull off something like this when you've got an issue? The importance of being able to debug and patch your mission critical systems is hard to overstate. Please encourage your employer to fiscally support the open s…
> For example, Microsoft may be changing their image, but their core software is closed source. may be great, but can you pull off something like this when you've got an issue? The importance of being able to debug and patch your mission critical systems is hard to overstate. Not OSS != no source access. A cloud provider on top of the MS stack would most likely have Shared Source Initiative licenses.