>
> On 3 Mar 1999, Jan Vroonhof wrote:
>
> > 1. Most of the gains come from less copying along pipes.
> > 2. [this is not clear from the paper to me] For the gains the occur
> > both sides of the pipe need use IOL.
> > 3. The gains come from copying by reference.
> > 3b. There is an additional gain from to having to recompute TCP
> > checksums.
>
> i think most gains come from the fact that IO-Lite only deals with
> 'immutable' (ie. read-only) IO buffers. Most (all) high-traffic sites have
> dynamic content ...
If the dynamic content is written properly, IO-Lite handles it as well.
And "written properly" isn't very hard to manage either.
Dynamic content is really a string of the form d1s1d2s2...dNsN, where dK
is dynamic (i.e. changes pretty much every request), and sK is static
(i.e. does not change frequently, is common between many requests).
In many many cases |s1s2...sN| > |d1d2...dN| ... by a large factor too --
that is to say, the pages are mostly static with a few bits of dynamic
fluff. Consider slashdot pages for example -- they consist of a bunch of
static fragments from various messages, arranged in some order. For these
pages, the dK are really short or non-existant... the sK are quite long in
comparison.
With IO-Lite all the sK can have their TCP checksums precalculated. If
the sK are large enough this is a win.
Obviously it doesn't apply to all dynamic content -- a web based email
client for example is all dynamic by my definition above. However much of
the content it displays is just copied from disk files. With IO-Lite that
copy isn't required -- the TCP checksum wins don't happen, but you can
reduce copies by one.
Sure, there's still complexity to be debated -- but don't dismiss the
paper out of hand before you've read the details... it does address a lot
of issues.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/