Message-Id: <1168327518.14963.38.camel@localhost.localdomain>
Date:	Mon, 08 Jan 2007 23:25:18 -0800
From:	"J.H." <warthog9@...nel.org>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Andrew Morton <akpm@...l.org>, Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>, hpa@...or.com,
	webmaster@...nel.org
Subject: Re: [KORG] Re: kernel.org lies about latest -mm kernel

On Tue, 2007-01-09 at 08:01 +0100, Jean Delvare wrote:
> Hi JH,
> 
> On Mon, 08 Jan 2007 13:33:04 -0800, J.H. wrote:
> > On Mon, 2007-01-08 at 22:20 +0100, Jean Delvare wrote:
> > > * Drop the bandwidth graphs. Most visitors certainly do not care, and
> > > their presence generates traffic on all web servers regardless of the
> > > one the visitor is using, as each graph is generated by the respective
> > > server. If you really like these graphs, just move them to a separate
> > > page for people who want to watch them. As far as I am concerned, I
> > > find them rather confusing and uninformative - from a quick look you
> > > just can't tell if the servers are loaded or not, you have to look at
> > > the numbers, so what's the point of drawing a graph...
> > 
> > While I agree that most users don't care, they are useful.  If someone
> 
> So moving them to a separate page would make sense.

Not really.

> 
> > notices that 1 has an incredibly high load and moving lots of traffic in
> > comparison to 2, than they can manually redirect to 2 for better &
> > faster service on their own.  Since these images aren't particularly big
> 
> Unfortunately the images actually fail to present this information to
> the visitor clearly. One problem is the time range displayed. 17
> minutes is either too much (hardly better than an instant value, but
> harder to read) or not enough (you can't really see the trend.) With
> stats on the last 24 hours, people could see the daily usage curve and
> schedule their rsyncs at times of lesser load, for example, if they see
> a daily pattern in the load.

They are useful, even if they are more or less a snapshot in time, as it
at least gives people a vague idea of whats going on.  So instead of
having to e-mail the admins and ask 'my download is slow' they can at
least glance at the graphs and possibly realize OHHHH it's release day
and kernel.org is moving close to 2gbps between the two machines.

> 
> Another problem is the fact that the vertical scales are dynamically
> chosen, and thus different between both servers, making it impossible to
> quickly compare the bandwidth usage. If the bandwidth usage on both
> servers is stable, both images will look the same, even though one
> server might be overloaded and the other one underused. The user also
> can't compare from one visit to the next, the graphs look essentially
> the same each time, regardless of the actual bandwidth use. So, if you
> really want people to use these graphs to take decsions and help
> balancing the load better, you have to use fixed scales.
> 
> I also notice that the graphs show primarily the bandwidth, while what
> seems to matter is the server load.
> 
> > they cache just fine and it's not that big of a deal, and there are much
> > longer poles in the tent right now.
> 
> The images are being regenerated every other minute or so, so I doubt
> they can actually be cached.
> 

Considering how many times the front page of kernel.org is viewed, yes
they are cached and sitting in ram on the kernel.org boxes.
Realistically - we are arguing over something that barely even registers
as a blip within the entirety of the load on kernel.org, and we have
bigger things to worry about than a restructuring of our front page when
it won't greatly affect our loads.

- John 'Warthog9'

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists