From: Jean Delvare <khali@linux-fr.org>
To: "J.H." <warthog9@kernel.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
Andrew Morton <akpm@osdl.org>, Pavel Machek <pavel@ucw.cz>,
kernel list <linux-kernel@vger.kernel.org>,
hpa@zytor.com, webmaster@kernel.org
Subject: Re: [KORG] Re: kernel.org lies about latest -mm kernel
Date: Tue, 9 Jan 2007 08:01:15 +0100 [thread overview]
Message-ID: <20070109080115.d7314b7a.khali@linux-fr.org> (raw)
In-Reply-To: <1168291984.14963.25.camel@localhost.localdomain>
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.
> 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.
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.
--
Jean Delvare
next prev parent reply other threads:[~2007-01-09 7:01 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-14 22:37 kernel.org lies about latest -mm kernel Pavel Machek
2006-12-14 23:01 ` Randy Dunlap
2006-12-14 23:38 ` Sergio Monteiro Basto
2006-12-16 17:44 ` [KORG] " Randy Dunlap
2006-12-16 17:57 ` Andrew Morton
2006-12-16 18:02 ` Randy Dunlap
2006-12-16 19:30 ` J.H.
2006-12-16 20:30 ` Russell King
2006-12-26 16:47 ` H. Peter Anvin
2006-12-16 21:21 ` Nigel Cunningham
2006-12-26 16:49 ` H. Peter Anvin
2007-01-07 3:35 ` Nigel Cunningham
2007-01-07 4:10 ` Jeff Garzik
2007-01-07 4:47 ` Nigel Cunningham
2007-01-07 4:22 ` Jeff Garzik
2007-01-07 4:29 ` Linus Torvalds
2007-01-07 20:11 ` Greg KH
2007-01-07 21:30 ` H. Peter Anvin
2007-01-07 21:54 ` Junio C Hamano
2007-01-07 22:21 ` Jeff Garzik
2007-01-07 22:53 ` Linus Torvalds
2007-01-07 23:32 ` Martin Langhoff
2007-01-07 5:17 ` H. Peter Anvin
2007-01-07 5:24 ` How git affects kernel.org performance H. Peter Anvin
2007-01-07 5:39 ` Linus Torvalds
2007-01-07 8:55 ` Willy Tarreau
2007-01-07 8:58 ` H. Peter Anvin
2007-01-07 9:03 ` Willy Tarreau
2007-01-07 10:28 ` Christoph Hellwig
2007-01-07 10:52 ` Willy Tarreau
2007-01-07 18:17 ` Linus Torvalds
2007-01-07 19:13 ` Linus Torvalds
[not found] ` <9e4733910701071126r7931042eldfb73060792f4f41@mail.gmail.com>
2007-01-07 19:35 ` Linus Torvalds
2007-01-07 10:50 ` Jan Engelhardt
2007-01-07 18:49 ` Randy Dunlap
2007-01-07 19:07 ` Jan Engelhardt
2007-01-07 19:28 ` Randy Dunlap
2007-01-07 19:37 ` Linus Torvalds
2007-01-07 9:15 ` Andrew Morton
2007-01-07 9:38 ` Rene Herman
2007-01-08 3:05 ` Suparna Bhattacharya
2007-01-08 12:58 ` Theodore Tso
2007-01-08 13:41 ` Johannes Stezenbach
2007-01-08 13:56 ` Theodore Tso
2007-01-08 13:59 ` Pavel Machek
2007-01-08 14:17 ` Theodore Tso
2007-01-08 13:43 ` Jeff Garzik
2007-01-09 1:09 ` Paul Jackson
2007-01-09 2:18 ` Jeremy Higdon
2007-01-09 7:59 ` Fengguang Wu
2007-01-09 7:59 ` Fengguang Wu
2007-01-09 16:23 ` Linus Torvalds
2007-01-10 1:57 ` Fengguang Wu
2007-01-10 1:57 ` Fengguang Wu
2007-01-10 3:20 ` Nigel Cunningham
2007-01-10 14:07 ` Fengguang Wu
2007-01-10 14:07 ` Fengguang Wu
2007-01-12 10:54 ` Nigel Cunningham
2007-01-07 14:57 ` Robert Fitzsimons
2007-01-07 19:12 ` J.H.
2007-01-08 1:51 ` Jakub Narebski
2007-01-08 1:51 ` Jakub Narebski
2007-01-07 15:06 ` Krzysztof Halasa
2007-01-07 20:31 ` Shawn O. Pearce
2007-01-08 14:46 ` Nicolas Pitre
2007-01-09 4:29 ` [KORG] Re: kernel.org lies about latest -mm kernel Nigel Cunningham
2007-01-09 5:09 ` Adrian Bunk
2007-01-09 5:51 ` Nigel Cunningham
2006-12-17 12:32 ` Pavel Machek
2006-12-17 13:13 ` Jeff Garzik
2006-12-17 18:23 ` Randy Dunlap
2006-12-17 22:37 ` Matti Aarnio
2006-12-18 0:42 ` J.H.
2006-12-19 6:46 ` Willy Tarreau
2006-12-19 7:39 ` J.H.
2006-12-19 13:32 ` Willy Tarreau
2006-12-19 14:36 ` Dave Jones
2006-12-19 14:38 ` Willy Tarreau
2006-12-26 16:14 ` H. Peter Anvin
2007-01-08 20:10 ` Jean Delvare
2006-12-19 6:34 ` Willy Tarreau
2006-12-19 6:52 ` J.H.
2007-01-06 18:33 ` Randy Dunlap
2007-01-06 19:18 ` H. Peter Anvin
2007-01-06 19:35 ` Willy Tarreau
2007-01-06 19:37 ` Nicholas Miell
2007-01-06 20:13 ` Andrew Morton
2007-01-06 20:18 ` H. Peter Anvin
2007-03-19 19:27 ` [PATCH] sysctl: vfs_cache_divisor Randy Dunlap
2007-03-19 20:36 ` Andrew Morton
2007-03-19 20:42 ` Randy Dunlap
2007-03-20 4:22 ` H. Peter Anvin
2007-03-21 23:01 ` Randy Dunlap
2007-03-21 23:11 ` Andrew Morton
2007-03-23 0:07 ` Kyle Moffett
2007-03-23 20:36 ` Randy Dunlap
2007-03-23 20:59 ` H. Peter Anvin
2007-03-24 0:45 ` Kyle Moffett
2007-03-24 1:17 ` Kyle Moffett
2007-03-20 19:53 ` Ingo Oeser
2007-01-06 23:50 ` [KORG] Re: kernel.org lies about latest -mm kernel H. Peter Anvin
2007-01-06 20:13 ` Jeff Garzik
2007-01-06 20:17 ` Andrew Morton
2007-01-06 20:20 ` H. Peter Anvin
2007-01-06 20:36 ` Andrew Morton
2007-01-06 19:21 ` J.H.
2007-01-07 19:52 ` Randy Dunlap
2007-01-07 23:56 ` H. Peter Anvin
2006-12-26 17:02 ` H. Peter Anvin
2007-01-08 19:31 ` Jean Delvare
2007-01-08 19:37 ` Willy Tarreau
2007-01-08 22:05 ` Jean Delvare
2006-12-19 15:37 ` Tim Schmielau
2007-01-08 21:20 ` Jean Delvare
2007-01-08 21:33 ` J.H.
2007-01-09 7:01 ` Jean Delvare [this message]
2007-01-09 7:25 ` J.H.
2007-01-09 13:36 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070109080115.d7314b7a.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=akpm@osdl.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=randy.dunlap@oracle.com \
--cc=warthog9@kernel.org \
--cc=webmaster@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.