Current time: 09-20-2019, 03:20 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bandwidth Graphs
06-24-2010, 05:18 AM
Post: #1
Bandwidth Graphs
Hey Patrick,

Many of us know what bandwidth is and many of us have heard the terms bandwidth in and bandwidth out.

I noticed you have a graph for bandwidth in for the test results.

How do we interpret this graph? Are spikes on the graph where our webpages are sending your testing servers static content?

Is there a maximum amount of bandwidth our servers can send or a maximum amount of bandwidth your server can receive during some time interval?

What does the ideal bandwidth graph look like? And how do we use the graph to make our performance better for the webpages?

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-24-2010, 05:21 PM
Post: #2
RE: Bandwidth Graphs
Hi Travis!

I think I can answer that. If you take a look at this example:

http://www.webpagetest.org/result/100624_EDV/1/details/

I tested from Frankfurt with FIOS, which corresponds to 20 Mbps as you can see in the bandwidth column of the test page.

This example page is roughly 0.5 Mbyte in size (to be precise 482 KB). So with a 20 Mbps line I should be able to have a maximum throughput of 2.5 MByte per seconds. In a perfect World ( no TCP Slow Start, no Latency ) this would mean, that my 0.5 Mbyte page should come down in ~0.2 seconds.

Unfortunately it doesn't. It actually took 4.5 seconds. Downloading 0.5 Mbyte in 4.5 seconds tells me, that I was downloading with an average of 1 Mbps. As I have a 20 Mbps line, I am at a rather bad bandwidth utilization of 5%.

So the graph tells you, at what place in time your bandwidth utilization was bad. In this example it is between 0.8 and 1.6 seconds.
As you can see in the waterfall, the reason for this was a lot of small files were fetched, with a rather long latency (time to first byte).
We could increase the utilization, if we would for example use image spriting, which concatenates all the small graphics to one large one.

So a high amount of small files downloaded with high latency is one possible reason for bad bandwidth utilization. Another example would be Javascript being executed, preventing the Browser from fetching further resources. Or excessive rendering. etc. etc.

Hope that helps a bit,
Kind regards,
Markus
Find all posts by this user
Quote this message in a reply
06-24-2010, 05:58 PM
Post: #3
RE: Bandwidth Graphs
Hey Markus,

Thanks for the great explanation for the bandwidth graph.

So If I have a 364 KB file which is being downloaded on a DSL connection (1.5 Mbps), in a perfect world I would have a maximum throughput of 0.1875 MBps and it would download in ~1.8958333 seconds.

364 KB * 1 MB / 1024 KB = 0.35546875 MB File Size

1 MBps (megabyte per second) = 8 Mbps (megabits per second)

0.1875 MBps = 1.5 Mbps

0.35546875 MB File Size / 0.1875 MBps Maximum ThroughPut = 1.8958333 seconds download time

http://www.webpagetest.org/result/100624_EER/4/details/

It looks like the reason this bandwidth was bad is because of the earthmail.jpg file took so long to download before the document complete events began, which brings me to my next question:

Is it possible to trigger the document complete event before images are done downloading?

I know it is possible to start downloading after the document complete event. I also know that the document complete event fires even if asynchronous javascript files are being downloaded, so why not images? Is there a way that anybody knows of?

In addition, you said one reason bad bandwidth occurs is because of latency sometimes caused by long times to first byte.

I started discussing this here a bit:

http://www.webpagetest.org/forums/showth...hp?tid=262

Times to first bytes on coldfusion pages for example can be caused by many backend database queries, but what causes long time to first bytes with images?

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-24-2010, 07:02 PM
Post: #4
RE: Bandwidth Graphs
(06-24-2010 05:58 PM)green-watch.org Wrote:  Hey Markus,

Thanks for the great explanation for the bandwidth graph.

So If I have a 364 KB file which is being downloaded on a DSL connection (1.5 Mbps), in a perfect world I would have a maximum throughput of 0.1875 MBps and it would download in ~1.8958333 seconds.

364 KB * 1 MB / 1024 KB = 0.35546875 MB File Size

1 MBps (megabyte per second) = 8 Mbps (megabits per second)

0.1875 MBps = 1.5 Mbps

0.35546875 MB File Size / 0.1875 MBps Maximum ThroughPut = 1.8958333 seconds download time

http://www.webpagetest.org/result/100624_EER/4/details/

It looks like the reason this bandwidth was bad is because of the earthmail.jpg file took so long to download before the document complete events began, which brings me to my next question:

Yep, between 2.7 and 4.7 seconds it downloads just 2.5 KByte worth of true data. That corresponds to a bandwidth of close to zero.

(06-24-2010 05:58 PM)green-watch.org Wrote:  Is it possible to trigger the document complete event before images are done downloading?

I know it is possible to start downloading after the document complete event. I also know that the document complete event fires even if asynchronous javascript files are being downloaded, so why not images? Is there a way that anybody knows of?

I assume that this could be done. Anyway, the question is, if that would improve the perceived performance by the customer? Or would be a rather "scientific" improvement, with no perceived improvement?

(06-24-2010 05:58 PM)green-watch.org Wrote:  In addition, you said one reason bad bandwidth occurs is because of latency sometimes caused by long times to first byte.

I started discussing this here a bit:

http://www.webpagetest.org/forums/showth...hp?tid=262

Times to first bytes on coldfusion pages for example can be caused by many backend database queries, but what causes long time to first bytes with images?

Sincerely,
Travis Walters

A reason could be Network congestion. Your TCP SYN or HTTP GET is delayed or even dropped in an overloaded routing queue along the network path.
Other reason could be an overloaded machine or Webserver, which is busy answering requests from other visitors to your site.

Kind regards,
Markus
Find all posts by this user
Quote this message in a reply
06-24-2010, 07:28 PM
Post: #5
RE: Bandwidth Graphs
Hey There,

(06-24-2010 07:02 PM)LeptienM Wrote:  I assume that this could be done. Anyway, the question is, if that would improve the perceived performance by the customer? Or would be a rather "scientific" improvement, with no perceived improvement?

It would improve the perceived performance. There is a little ajax wheel turning on product images while that one image is being downloaded. The product images are not downloaded until the on document complete event fires. So because of that single image in that particular case, the product images would have been perceived as being loaded slowly.

(06-24-2010 07:02 PM)LeptienM Wrote:  A reason could be Network congestion. Your TCP SYN or HTTP GET is delayed or even dropped in an overloaded routing queue along the network path. Other reason could be an overloaded machine or Webserver, which is busy answering requests from other visitors to your site.

Well I am on a dedicated server with one other person. My website is under development and his website gets minimal traffic. I really doubt the webserver would be extremely busy. This leads me to believe it might be the other case where the network path may be slow. I suppose there is nothing you can do about this? Please note, I am using a CDN.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
06-25-2010, 03:30 AM
Post: #6
RE: Bandwidth Graphs
The bandwidth graph is more just an indicator of when data is coming in. I've debated removing it but it is helpful to see when the page is actually downloading stuff (useful work) and when it's not (wasted time). This can help a fair bit when you flush the document early to see the initial chunk of data coming in and to make sure that data continues to come in from then on.

Don't pay too much attention to the absolute scale because the raw measurements will not be very accurate (just by definition in how things are measured from the client side).
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)