ietf-nntp OVER and HDR parameter comments

[Andrew Gierth]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 >>> Whether the particular header is cached in some way shouldn't be
 >>> an issue.  If the client really wants/needs a header, its going
 >>> to get it by grabbing the HEAD and then parsing it itself.

 >> Yes, but clients expect that command to be slower, and that puts
 >> more work on the client.  The client can only retrieve one header
 >> at a time.  HDR on the other hand can be applied to thousands of
 >> articles with a single command, and can put an extremely
 >> disproportionate load on the server.

 Ken> Yes, but if the client is going to fetch the header itself via
 Ken> thousands of HEAD commands, that will eat bandwidth.  It comes
 Ken> down which is cheaper.  I'm guessing that server CPU is cheaper
 Ken> than bandwidth, but I could be completely full of shit.

it's not server CPU that takes the hit, it's server disk I/O, which is
usually at a premium on a news server (and is certainly much more
expensive at the server end than the relatively trivial amount of
bandwidth involved in lots of HEAD commands). Basically it comes down
to the difference between a small number of linear read requests (to
fetch a range from the overview database) and a much larger number of
small and very random reads to fetch article headers from the spool.

The real problem with HDR (or worse, XPAT) on arbitrary headers
implemented by opening all the actual articles is that the server load
is disproportionate to the bandwidth involved, which means that a
relatively modest number of low-bandwidth clients can bring the server
to its knees (unless the server introduces arbitrary delays). Add to
that the fact that client implementations are more likely to try and
optimize for minimum bandwidth use...

-- 
Andrew.