This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients eric.araujo, giampaolo.rodola, neologix, pitrou, rosslagerwall
Date 2013-03-06.19:49:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1wwpqKJtQVTqNtrDwh2TZrPcuSW2E+GPwF4XaSpZtg+A@mail.gmail.com>
In-reply-to <1362593397.98.0.766187186143.issue13564@psf.upfronthosting.co.za>
Content
> Specifying a big blocksize doesn't mean the transfer will be faster.
> send/sendfile won't send more than a certain amount of bytes anyways.

The transfer won't be faster mainly because it's really I/O bound.
But it will use less CPU, only because you're making less syscalls.

> If I'm not mistaken I recall from previous benchmarks that after a certain point (131072 or something) increasing the blocksize results in equal or even worse performances.

I can perfectly believe this for a send loop, maybe because you're
exceeding the socket buffer size, or because your working set doesn't
fit into caches anymore, etc.
But for sendfile(), I don't see how calling it repeatedly could not be
slower than calling it once with the overall size: that's how netperf
and vsftpd use it, and probably others.

> Another thing I don't like is that by doing so you implicitly assume that the file is "fstat-eable". I don't know if there are cases where it's not, but the less assumptions we do the better.

Well, the file must be mmap-able, so I doubt fstat() is the biggest concern...
History
Date User Action Args
2013-03-06 19:49:04neologixsetrecipients: + neologix, pitrou, giampaolo.rodola, eric.araujo, rosslagerwall
2013-03-06 19:49:04neologixlinkissue13564 messages
2013-03-06 19:49:04neologixcreate