What means the light part of the bar?


What means the light part of the bar?

This makes most of my loading time.



Freeboard.at - Free Forum - Free Bulletin Board Forum advertising-free for your Community based on phpBB! Freeboard with great Features and easy Handling!

That is the time for the server to respond to the http request. Looking at the orange bars for requests 4-7, it looks like that might be the RTT to the server though and using a CDN is likely the only way to make it faster.


But, what does it mean when the bar in 1 row is light, then dark for a short time and then light for a 2nd time again and so on…

Seems as if several TCP packets containing the HTTP data are received with timely distance? Can’t I tell the apache 2.0 server to, at least for the HTML contents which are in size of some KB, to send only 1 TCP packet (and this one with highest priority)?

If more packets are sent and all at the same time, what causes that huge delays? They should be taking the same route right?



edit: 1 line is 1 file here

Each TCP packet is ~1400 bytes of data. There is no way to send all of the HTML in one “packet”. There is tcp slow start which ramps up the number of packets in-flight and setting a higher initial congestion window can send more on the initial burst (it used to be 2-4 and more recently 10 packets is the general guidance). That needs to be done on the server (at the OS level, not Apache).

It could also be the application if the page isn’t completely generated before responding. Early flushing of the HTML is a common practice to help boost performance by sending the headers and HTML head while slower back-end queries happen and then send the rest. Hard to say if that’s the case here without knowing the app better.

The data flow is also going to depend on what else is going on in the waterfall at the time since all of the connections share the same pipe. In this case there are the SSL certificates and javascript downloading for request #9 that will contend for bandwidth with the HTML.

Looking at the waterfall, the gaps are in an image download, not the HTML so the HTML early flushing won’t come into play. Mostly just TCP slow start and any bandwidth contention with other resources.

Hi pmeenan,


I also tried HTML early flushing now and I do see some improvements since images are already requested after 2/3 of the HTML is received, thus some 100ms earlier:

There should be no bandwidth contention with other resource, my server even doesn’t have SSL support compiled within the PHP module, this part (the SSL certificates and javascript downloading for request #9) in the screenshot was a request on google analytics, but all the images come from my server where each request shows up as these light-coloured bars of 99% latency and 1% actual data download. Since 97% of file requests on my server are less than 10KB files, I am really focused on boosting up TCP slow start now.

EDIT: Also, I am wondering why clients establish multiple HTTP connections in spite of having keep-alive in place (6 or so in Firefox by default even when keep-alive is on). This is, why only ~50% (can be seen by the multiple orange HTTP connects in the screenshot) of the associated files of a pageload (which are all very small, ~10KB) are transmitted over a reused HTTP connection. And for half of the 10KB files associated with a pageload, a new HTTP connection means also a new TCP connection with a new TCP slow-start ramp-up, right? Or can a TCP connection be reused for different higher level HTTP connections?
If not and TCP slow-start starts with 2-3 packets, after approx. 3 SYN-ACKS, one file has been sent (eg. a small gif image), and if that HTTP connection isn’t reused, a new tcp connection will also be the consequence. So there is a huge impact from the higher HTTP layer on the TCP slow start issue too, if a TCP connection cannot be reused for different higher level HTTP connections?

Best Regards


I don’t think you can tune initcwnd in Windows 2000: http://smallvoid.com/article/winnt-tcp-slow-start.html

All browsers open several connections to the same server so they can request multiple resources concurrently, otherwise you’d have to wait for the request/response latency for each one serially and the connection would spend most of the time idle (but yes, each new connection needs to pay the slow-start penalty). With HTTP/2 (only available with HTTPS) the requests can be multiplexed over a single connection and browsers can fetch all of the content concurrently (and the server sends it back in priority order).

The DNS time variations probably come down to what the TTL is on the DNS records if they are cached by the ISP or if it has to go back to the authoritative server.

Honestly, I think your best option without completely changing the hosting is to just sign up for a free Cloudflare account and put your site behind their CDN: https://www.cloudflare.com/ (or any other CDN but given the age of the hosting I’m assuming you aren’t looking to throw a lot of money at it).

Any CDN has already tuned the initcwnd and will be much closer to the browser which makes the RTT’s much faster as well. It looks like most of the images are also cacheable so they can cache and serve them directly from the edge without ever going back to your origin.

If you want to do it yourself then your best option is a modern Linux box of some kind in front of the win2k server.