Quote:
Originally Posted by dozey
I realise you probably quoted this from somewhere else, but frankly, it is wrong.
|
No, I attribute when I quote, and frankly most everything you said is obviously
ridiculous if one takes 20 seconds to think it through, as I will show.
Quote:
|
Rubbish. Pages should load in < 1 second over any decent "maxed out" connection. That's obviously not the case.
|
Let's take 20 seconds to do the math:
This page, for example, is 341 KB.
Multiply by 8, that's 2731 Kb.
Add 8% TCP overhead, your connection must transfer 2950 Kb.
The most popular high speed connection in the US, SBC standard DSL,
is capped at a theoretical MAXIMUM of 1500Kbs, though it generally
runs closer to 900Kbs. So to load this page in under a second one
would need a connection at least three times as fast as the typical
high speed connection. You are 300% wrong.
Quote:
|
Again, chances are the bottleneck lies somewhere other than your computer...
|
Let's do 20 seconds of math:
On the three servers I just checked, on average they have 11 connections
currently sending data. One has a 10 Mbps connection, the other two are
unknown, but 10Mbps is reasonable. Therefore, they can send 900Kbps
on each connection. Note that this just happens to be the same as the
typical speed of most people's $25 DSL connection. These servers can
max out your internet connection using just ONE concurrent connection.
You said that 40 wouldn't max it out. You are 4000% wrong.
Quote:
|
Presumably this means the connection has timed out. If not, you have bigger problems.
|
Rathet than
presuming, how about listening to the guy who wrote the
code in the first place? You get broken images because Apache tells you and
your 40 connections to screw off, sending a 509 error status most of the time.
We send a 302 redirect to an error document if you're using IE AND are
downloading a very large file, due to the fact the IE's download manager is
stupid in it's treatment of the 509. I'm not
presuming this - I wrote
that part of Apache.
Quote:
Quote:
have to wait for the whole page to load before you
see even the first image at the top of the page appear.
|
Once again, the chances are this isn't an issue of concurrency. These delays are attributable to the browser's rendering behavior, as noted in instruction #3; "This value is the amount of time the browser waits before it acts on information it recieves."
|
This is almost the definition of concurrency. The browser can't render anything
that it hasn't downloaded. If you have it downloading all 40 images at once,
they will all finish at about the same time, so the you must wait until all 350KB
can be downloaded before anything can be rendered. Stop a second here and
take 20 seconds to think this through before replying and embarrassing yourself.
This is the classic problem that has to be addressed in any software that
provides a service to other processes, whether it be an internet server
like Apache or a COM server. If you have one request or connection at
a time, each one can be handled very quickly, then when that one finishes
you do the next, then the next, on down the line, spitting out responses
serially. On the other hand, if you handle 40 things at a time, those 40
things all have to share your CPU / network connection / printer or whatever
the bottleneck is, so they take 40 times as long, then after a long wait they
suddenly all complete at once. Google "introduction to multithreading" or
the like for further discussion and examples.
Please, if you are a webmaster who spends his days building sites and
marketing, share your knowledge and experience in that area. If you
have an interest in internet protocols and software engineering, these are
interesting fields to study. But please take some time to study some of
the resources I can suggest before you continue to argue that which you
do not know. To realyl understand the browser, come on over to the
Mozilla Foundation, where we build Firefox. Browse through our bug tracker
to see how things work. You'll find closed ones, things we've done,
and open ones, things we're doing or may do in the future. Read through
the user documentation, then read the HTTP protocol at W3C. After
that, read the developer documentation and start working on some bugs.
You'll learn a LOT about the browser that way. To truly understand the
Apache server, check out the user and developer documentation and
mail groups such as modules-dev, the group for people developing
modules which load in to become part of Apache. You'll find me there,
a relative newbie to that group, and true experts such as Nick Kew, author
of "The Apache Modules Book", THE book about Apache internals. Nick is
a nice guy and always willing to answer intelligent questions.
To really learn about protocols such as HTTP, SMTP, etc., you are welcome
to join the Internet Engineering Task Force. The IETF is where we plan new
versions of HTTP, the protocol of the web, SMTP, the email protocol, and
most of the other specifications for how your computer interacts with the
rest of the internet. This group is the "hangout" of some of the best known
minds in internet technology, such as Vint Cerf, who invented the TCP/IP
protocols that the entire internet runs on. (Don't call him Vinton). You are
welcome to join today and start reading, being a part of the day to day work
we do on essential protocols that virtually every internet connected device
either uses today or will use ten years from now. This IS a high level group
of really smart people, so please read for a while and of course read and
thoroughly understand the actual protocol specifications before adding to the
discussion. Some of the suggestions and attitudes in this thread would NOT
be handled with the same polite education in IETF discussion. Rather, you
would probably be told quite rudely to stop wasting knowledable people's
valuable time and go ... well, it would be rude for me to say it. Let's just
say they would not be nearly as polite as I've been here.
