Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Reply | 11 comments | Create New Account
Click here to return to the 'Reply' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Reply
Authored by: david-bo on Jan 29, '03 05:17:03PM

Guy, the guy (!) who wrote the original text, has commented on the comments found here:

------
Date: 2003-01-27 01:18
Sender: nobody
Logged In: NO

Looks like I have to watch out what I say around here. Some
of your readers do seem to agree now that their
browsing has been improved using the information we both made
available to them.

There are two statements that stand out:
1) Me, saying "Others may disagree."
2) The one who said "This guy doesn't know what he's talking
about."

Seriously though, there may be no single answer for everybody.
If someone spends all their time at one specific
site that has an HTTP server specifically designed for pipelining,
then that will do very well. On the other hand,
someone who peeps at only very simple sites may be better served
with older HTTP/1.0 non-persistent
connections.

I would like to highlight how the "average" or
"common" browsing pattern is contradictory to
pipelining:

- You hit a page.
- As that HTML is retrieved the browser sees and fetches bunches
of GIF, JPG, CSS, JS, etc. that are specified as
part of that page. A "Burst" of requests.
- Then a long delay while the human absorbs the content.
- Then click to something else == Repeat.

That's not what pipelining will be good at supporting. Instead
you need an architecture designed for bursts of
distinct communication - which in today's technology should involve
multiple concurrent threads and several
concurrent TCP sockets. In the real-world testing that I have
done, persistence beyond a few seconds is irrelevant
- and everything crawls with a single pipe.

Just turn on Privoxy's URL logging to a file for a few hours
then review it. You'll see bursts of requests happening
simultaneously with some time lag between them. It's pretty
rare for a single lonely request to a site, and it's also
rare for 100 requests to the same site in the same burst. With
advertisements, the burst consists of intermingled
requests to a couple of sites.

How would YOU design an architecture to accommodate that? If
your answer is to group all sites within a burst
together and hand the whole mess to some other server - then
Pipelining is your answer. Sort of like delegating
responsibility saying "I don't know how to handle all that
stuff very well, so it's your job".

In contrast, re-used HTTP/1.1 connections work quite differently.
In this method a browser would open a handful
(default 2, I like more) connections to a server - and as each
is satisfied it then shoves another one down that
same pipe. It is quite common for one connection to be reused
several times before the first one gets done with
its reply. Some requests take longer to process, often just
due to sheer size. And while these requests are being
satisfied, the data is being pumped back to the browser - which
is then using multiple threads to render the page
as the various pieces complete. That's the real world that I
live in.

You see, there's at least 2 computers capable of multiple threads
to produce the result. By having only a single
pipe or two, neither computer can bring its resources to bear
on the task at hand. It just doesn't make much sense
unless the expense of opening a TCP socket is exceedingly expensive
- and it's not.

==========

Here's some other arguments against Pipelining in the "real
world" of multi-threading:

- Even if opening a subsequent TCP socket IS exceedingly expensive,
then reused HTTP/1.1 connections would
still be piped to the previously completed sockets instead of
delaying anything else.

- You can open a bunch of TCP sockets concurrently much faster
than if opening each one at a time. So the initial
TCP socket overhead associated with establishing a connection
is mostly a parallel event, not a serial event. The
overhead does not accumulate, and it must be incurred at least
once when pipelining anyway.

- When the HTTP/1.1 RFC was written, the above 2 items were not
as true. Netscape was the first to introduce
socket reusability for HTTP/1.0, a sub-protocol that wasn't properly
implemented in some other browsers. Many
client PC's, ISP's, and backbone routers were each individually
subject to bigger performance issues as the
number of concurrent connections increased. OS TCP stacks and
internet routers have evolved significantly since
then. So I think Pipelining is a method which was being voided
about the same time it was being specified.

- For the advanced college types, the applicable topic is
"Queuing Theory". Pipelining is where you drop the
class
to avoid an F because you haven't got a clue how to apply any
of it.

==========

Regarding Pipelining being supported by all HTTP/1.1 servers:
Sure, it's called a QUEUE where activity on a 2nd
request is delayed until the 1st one is completed. Remember
that Pipelining REQUIRES the complete response
for each request to be streamed in exactly the sequence that
was requested. The server can not complete several
requests simultaneously and hope they accidentally come out in
sequence. The server is FORCED to queue
either the incoming requests, OR the outgoing results. Either
way, it must put you on hold for a while someplace.

Meanwhile, your Number5 browser is loafing back at the ranch
"I need Input". It does help keep your processor
from overheating. It can also help ensure that speedy new machines
will remain competitive with existing low-end
machines :)

==========

And now a clarification about Privoxy. Future plans are to better
address reusing HTTP/1.1 connections. Currently
the methods employed through Privoxy do not fully illustrate
the performance variance. Benchmarking the two
methods may be more accurate without Privoxy skewing any
results.

I encourage the members of your other forum to please do some
of their own research. And those that grasp the
issues - whether they agree with me or not - are encouraged to
join us in this project as we improve the product.

Interesting topic, thanks for the opportunity to respond here.
Say HI to your forum for me.

Guy.

------
Date: 2003-01-27 01:45
Sender: nobody
Logged In: NO

OOPS. I was enjoying writing the response so much I didn't proofread
it enough. There's an important
misrepresentation of what I meant to say in one of
the paragraphs.

The sentence currently reads:

If your answer is to group all sites within a burst together
and hand the whole mess to some other server - then
Pipelining is your answer.

Should have been (upper casing variance):

If your answer is to group all THE REQUESTS FOR EACH SITE within
a burst together and hand EACH GROUP
IN ITS ENTIRETY to A server - then Pipelining is your answer.

Guy.

------



[ Reply to This | # ]
It works for me!
Authored by: malvolio on Feb 11, '03 11:45:47AM

Turning off pipelining and editing my user.js file as recommended has given a significant speed boost to both Mozilla and Chimera.
Sweeeet!



[ Reply to This | # ]