4 ms·

Any well written server application eventually comes down to how fast can you copy the data. This avoids a copy so it can double performance. As for headers/t

Any well written server application eventually comes down to how fast can you copy the data. This avoids a copy so it can double performance. As for headers/trailers, it's a file descriptor, nothing prevents you from writing to it before or after the sendfile() call. Simple primitives are fine but this is faster. Unless you are going to do the page flipping tricks that Irix did, you can't approach this speed (and Irix tricks aren't as fast as this, better than the bcopy() but not as fast as this).

Matthias247 11y ago
Reality is sometimes a bit different from theory here. Let's say you want to send a small amount of data (1k) from a file to network, some header before it and some trailer behind it. With sendfile you would do three system calls, two normal writes and a sendfile. Without it you would read the file, copy the content, the header and the trailer into a single buffer and issue a single write syscall with it (of course you have the read call before). Due to the lower number of write calls this could be faster then sendfile, as copying a small amount of data might yield a lower overhead then multiple write requests. Of course that situation will change depending on the amount of data - so I think sendfile is one possible optimization that should be benchmarked for the particular application before using it everywhere.
- paulddraper 11y ago
  Three syscalls instead of one will probably not make a difference. Copying a 50mb file multiple times will.
  - ryanpetrich 11y ago
    But they aren't free and if the file size is sufficiently small, the overhead of the constant overhead of the additional syscalls will dwarf the variable overhead of the extra copy. FreeBSD/OS X's sendfile allows specifying a header and trailer in a single syscall to avoid this limitation.
    - paulddraper 11y ago
      I'd be interested in reading how small the file has to be for this to be necessary.
- luckydude 11y ago
  I'm well aware of this, there is a set of benchmarks in lmbench, which I wrote, that shows something similar to what you are talking about. I called it open to close performance and it plotted the MB/sec as a function of file size for read/write vs mmap. One would think that mmap is faster because it does less work but that's not true if you include the open/mmap, read is always fast in that case (which is surprising to me, it used to be that there was a cross over point). But your whole comment sort of misses the point of sendfile. If you are doing little file transfers, use read/write, they are fine. The overhead of the syscalls matter if the size is small. But sendfile is for big data and there the limit, of perf, as the size goes to infinity, is 2x.

Matthias247 11y ago

Reality is sometimes a bit different from theory here. Let's say you want to send a small amount of data (1k) from a file to network, some header before it and some trailer behind it. With sendfile you would do three system calls, two normal writes and a sendfile. Without it you would read the file, copy the content, the header and the trailer into a single buffer and issue a single write syscall with it (of course you have the read call before). Due to the lower number of write calls this could be faster then sendfile, as copying a small amount of data might yield a lower overhead then multiple write requests. Of course that situation will change depending on the amount of data - so I think sendfile is one possible optimization that should be benchmarked for the particular application before using it everywhere.

paulddraper 11y ago
Three syscalls instead of one will probably not make a difference. Copying a 50mb file multiple times will.
- ryanpetrich 11y ago
  But they aren't free and if the file size is sufficiently small, the overhead of the constant overhead of the additional syscalls will dwarf the variable overhead of the extra copy. FreeBSD/OS X's sendfile allows specifying a header and trailer in a single syscall to avoid this limitation.
  - paulddraper 11y ago
    I'd be interested in reading how small the file has to be for this to be necessary.
luckydude 11y ago
I'm well aware of this, there is a set of benchmarks in lmbench, which I wrote, that shows something similar to what you are talking about. I called it open to close performance and it plotted the MB/sec as a function of file size for read/write vs mmap. One would think that mmap is faster because it does less work but that's not true if you include the open/mmap, read is always fast in that case (which is surprising to me, it used to be that there was a cross over point). But your whole comment sort of misses the point of sendfile. If you are doing little file transfers, use read/write, they are fine. The overhead of the syscalls matter if the size is small. But sendfile is for big data and there the limit, of perf, as the size goes to infinity, is 2x.