Hi Andre,
Here is another thought that might explain things. Suppose a web page has up to 10 22KB images for tabs and the browser opens up say 8 sockets and the bandwidth of the user was 1Mbps. Would the fact that many sockets were allowed by the browser saturate the user side bandwidth? Like CPU utilization the network folks might normally want to run it lower else the number of collisions might get so high the overall effect might be a large delay or load time.
I thought somewhere on the Apache site there was a recommendation to number of images to a page and the size?
Just wondering,
-Tony
--- On Tue, 2/17/09, Tony Anecito <adanecito@xxxxxxxxx> wrote:
> From: Tony Anecito <adanecito@xxxxxxxxx>
> Subject: Re: Why Would Apache be so slow??
> To: users@xxxxxxxxxxxxxxxx
> Date: Tuesday, February 17, 2009, 10:10 PM
> Hi Andre,
>
> Thanks for the writeup. I have fiber instead of copper but
> I suspec the fiber is shared by putting in some type of
> optical hub perhaps.
>
> That said I had a troubleshooting session with the ISP and
> it was narrowed down to the network somewhere. He wanted me
> to bypass the router so I just went an bought another one
> since it was an old one anyway but it did not make a
> difference. I later called the company hosting my url
> godaddy and they did some tests but could not fault the DNS
> and I ran some DSL performance tests myself and the DNS
> seemed fast enough. I do have wireshark installed but have
> not tried capturing traffic to see if anything can be
> gleemed from it.
>
> Funny thing was godaddy tested the url and it did not seem
> slow to them. Which made the issue even more confusing.
>
> So I am down to the ISP's device to convert light
> signals the ethernet and dsiabling the remaining two
> comnputers on the network tonight. I will try powering down
> the light to ethernet converter after the 2 computers are
> offline to see what happens.
>
> Again many thanks and I will run those tests after I get to
> the root cause of the performance issue.
>
> -Tony
>
>
>
>
> --- On Tue, 2/17/09, André Warnier <aw@xxxxxxxxxx>
> wrote:
>
> > From: André Warnier <aw@xxxxxxxxxx>
> > Subject: Re: Why Would Apache be so
> slow??
> > To: users@xxxxxxxxxxxxxxxx
> > Date: Tuesday, February 17, 2009, 4:57 PM
> > In short, what your tests are showing you is that
> Apache on
> > its own (not quite, but close enough) gives you the
> file in
> > 20 ms. The rest (the 5000 ms you measured before,
> minus 20
> > ms) is the network.
> > Score : Apache 1, network 249.
> > That should give you a pretty good indication of what
> to
> > focus on next.
> >
> > In many more words :
> >
> > First about the Apache cache : get rid of it.
> > The server-side cache will only slow down things for
> this
> > type of test. It only helps if you have many requests
> /for
> > the same file/ in a given period of time. If you have
> only
> > one, then you are just forcing the server not only to
> send
> > the response to the browser, but also to copy this
> response
> > to the cache.. You are also forcing the server to look
> in
> > the cache each time, to see if the file is there. And
> if it
> > is there, it anyway has to read it before sending it
> to the
> > browser.
> > In addition, if the cache is in memory, then you are
> also
> > using up memory that could be better used somewhere
> else.
> >
> > Note that it would be much better to do the tests
> below
> > with a non-graphical barebones test program such as
> > Apache's ab, or wget, or curl, or (my preferred
> one for
> > this) lwp-request (perl).
> > Then you could write a script which measures the time
> from
> > the client side, and which repeats the above accesses
> any
> > number of times automatically. But if you like
> typing..
> >
> > Clear the browser cache.
> > Then try with 3 files, one after the other, with the
> > browser on the same machine as Apache :
> > - one fairly small, like the 20KB file you have been
> > testing with
> > - one say 250 KB
> > - one say 1MB
> > To be fair and avoid secondary effects, make (or get)
> an
> > "index page" showing links to your 3 files,
> and to
> > measure the time right-click on each link and do a
> > "save as..". This way you are really
> measuring
> > the time it takes Apache to serve it, and not for
> example
> > the time it takes your browser to display the page, or
> image
> > or whatever.
> > Got to eliminate the secondary effects.
> >
> > I bet that the difference in time, with the browser on
> the
> > same machine as Apache, will not be very large between
> the 3
> > above.
> > I don't remember what mod_logio exactly measures,
> but
> > if it is the total time between the arrival of the
> request
> > up to the time the complete response has gone out of
> Apache,
> > then remember that
> > a) one fixed element is the time to process the
> request,
> > finding the file etc.. That's the same no matter
> how
> > big the file.
> > b) the variable element is the time to send the
> response,
> > which depends on the response size and how fast the
> line is
> > and ..how fast the client is to read and save the
> response.
> > With the server-local browser, (b) depends essentially
> on
> > the speed of your disks.
> > You may want to repeat these tests a number of times,
> to
> > also eliminate the fact that your server (apart from
> Apache)
> > also has a disk cache. So the second time you ask for
> the
> > same file is likely to be faster, independently of
> Apache.
> > So run the above 3 downloads 5-6 times each at least,
> > discard the first one, then discard the longest and
> the
> > shortest, and average the rest.
> > You may also want to make sure that there is nothing
> else
> > significant running on your server, to eliminate those
> > effects (email server ? automatic disk indexing ?
> automatic
> > updates ?). Etc.. etc...
> > Running real benchmarks is not so easy.
> >
> > Anyway, the above times are your baseline.
> > Now try again the same 3 files with a browser on
> another
> > machine of your local network.
> > The difference with the first test will give you the
> time
> > your local network is adding to the baseline.
> > Then try again, going through your Internet
> connection.
> > Then you will see how much that is adding.
> >
> > When your ISP is renting you a DSL line for 3 Mbit/s,
> you
> > have to realise that he is also renting the same to
> your 100
> > neighbours. But he is not expecting you and all your
> 100
> > neighbours, at the same time, to be using the full 3
> Mbit/s
> > each. So his line has a total capacity of say 100
> Mbit/s at
> > best (instead of 300 Mbit/s), and he figures that on
> average
> > you and the neighbours will be satisfied. If you read
> the
> > fine print, you'll probably see that somewhere it
> says
> > "/up to/ 3 Mbit/s".
> > So if your neighbours are reading this, and trying the
> same
> > thing at the same time, don't be surprised if
> several
> > tests show widely different answers.
> >
> >
> >
> ---------------------------------------------------------------------
> > The official User-To-User support forum of the Apache
> HTTP
> > Server Project.
> > See <URL:http://httpd.apache.org/userslist.html>
> for
> > more info.
> > To unsubscribe, e-mail:
> users-unsubscribe@xxxxxxxxxxxxxxxx
> > " from the digest:
> > users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> > For additional commands, e-mail:
> > users-help@xxxxxxxxxxxxxxxx
>
>
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP
> Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for
> more info.
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> " from the digest:
> users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail:
> users-help@xxxxxxxxxxxxxxxx
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|