From: Jakub Narebski <jnareb@gmail.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Jeff Garzik <jeff@garzik.org>,
Martin Langhoff <martin.langhoff@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Rogan Dawes <discard@dawes.za.net>,
Kernel Org Admin <ftpadmin@kernel.org>
Subject: Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
Date: Sun, 10 Dec 2006 21:27:05 +0100 [thread overview]
Message-ID: <200612102127.05894.jnareb@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0612101129190.12500@woody.osdl.org>
Linus Torvalds wrote:
> On Sun, 10 Dec 2006, Jakub Narebski wrote:
>>>> If-Modified-Since:, If-Match:, If-None-Match: do you?
>>
>> And in CGI standard there is a way to access additional HTTP headers
>> info from CGI script: the envirionmental variables are HTTP_HEADER,
>> for example if browser sent If-Modified-Since: header it's value
>> can be found in HTTP_IF_MODIFIED_SINCE environmental variable.
>
> Guys, you're missing something fairly fundamnetal.
>
> It helps almost _nothing_ to support client-side caching with all these
> fancy "If-Modified-Since:" etc crap.
>
> That's not the _problem_.
>
> It's usually not one client asking for the gitweb pages: the load comes
> from just lots of people independently asking for it. So client-side
> caching may help a tiny tiny bit, but it's not actually fixing the
> fundamental problem at all.
Well, the idea (perhaps stupid idea: I don't know how caching engines
/ reverse proxy works) was that there would be caching engine / reverse
proxy in the front (Squid for example) would cache results and serve it
to rampaging hordes. But this caching engine has to ask gitweb if the
cache is valid using "If-Modified-Since:" and "If-None-Match:" headers.
If gitweb returns 304 Not Modified then it serves contents from cache.
> So forget about "If-Modified-Since:" etc. It may help in benchmarks when
> you try it yourself, and use "refresh" on the client side. But the basic
> problem is all about lots of clients that do NOT have things cached,
> because all teh client caches are all filled up with pr0n, not with gitweb
> data from yesterday.
What about the other idea, the one with raising expires to infinity for
immutable pages like "commit" view for commit given by SHA-1? Even if
the clients won't cache it, the proxies and caches between gitweb and
client might cache it...
Talking about most accessed gitweb pages, the project list page changes
on every push, the project summary page and project main RSS feed
(now in both RSS and Atom formats) changes on every push to given project.
With a help of hooks they can be static pages, generated by push...
...with the exception that projects list and summary pages have _relative_
dates.
--
Jakub Narebski
next prev parent reply other threads:[~2006-12-10 20:25 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <45708A56.3040508@drzeus.cx>
[not found] ` <Pine.LNX.4.64.0612011639240.3695@woody.osdl.org>
[not found] ` <457151A0.8090203@drzeus.cx>
[not found] ` <Pine.LNX.4.64.0612020835110.3476@woody.osdl.org>
[not found] ` <45744FA3.7020908@zytor.com>
[not found] ` <Pine.LNX.4.64.0612061847190.3615@woody.osdl.org>
[not found] ` <45778AA3.7080709@zytor.com>
[not found] ` <Pine.LNX.4.64.0612061940170.3615@woody.osdl.org>
[not found] ` <4577A84C.3010601@zytor.com>
[not found] ` <Pine.LNX.4.64.0612070953290.3615@woody.osdl.org>
[not found] ` <45785697.1060001@zytor.com>
2006-12-07 19:05 ` kernel.org mirroring (Re: [GIT PULL] MMC update) Linus Torvalds
2006-12-07 19:16 ` H. Peter Anvin
2006-12-07 19:30 ` Olivier Galibert
2006-12-07 19:57 ` H. Peter Anvin
2006-12-07 23:50 ` Olivier Galibert
2006-12-07 23:56 ` H. Peter Anvin
2006-12-08 11:25 ` Jakub Narebski
2006-12-08 12:57 ` Rogan Dawes
2006-12-08 13:38 ` Jakub Narebski
2006-12-08 14:31 ` Rogan Dawes
2006-12-08 15:38 ` Jonas Fonseca
2006-12-09 1:28 ` Martin Langhoff
2006-12-09 2:03 ` H. Peter Anvin
2006-12-09 2:52 ` Martin Langhoff
2006-12-09 5:09 ` H. Peter Anvin
2006-12-09 5:34 ` Martin Langhoff
2006-12-09 16:26 ` H. Peter Anvin
2006-12-08 16:16 ` H. Peter Anvin
2006-12-08 16:35 ` Linus Torvalds
2006-12-08 16:42 ` H. Peter Anvin
2006-12-08 19:49 ` Lars Hjemli
2006-12-08 19:51 ` H. Peter Anvin
2006-12-08 19:59 ` Lars Hjemli
2006-12-08 20:02 ` H. Peter Anvin
2006-12-10 9:43 ` rda
2006-12-08 16:54 ` Jeff Garzik
2006-12-08 17:04 ` H. Peter Anvin
2006-12-08 17:40 ` Jeff Garzik
2006-12-08 23:27 ` Linus Torvalds
2006-12-08 23:46 ` Michael K. Edwards
2006-12-08 23:49 ` H. Peter Anvin
2006-12-09 0:18 ` Michael K. Edwards
2006-12-09 0:23 ` H. Peter Anvin
2006-12-09 0:49 ` Linus Torvalds
2006-12-09 0:51 ` H. Peter Anvin
2006-12-09 4:36 ` Michael K. Edwards
2006-12-09 9:27 ` Jeff Garzik
[not found] ` <4579FABC.5070509@garzik.org>
2006-12-09 0:45 ` Linus Torvalds
2006-12-09 0:47 ` H. Peter Anvin
2006-12-09 9:16 ` Jeff Garzik
2006-12-09 1:56 ` Martin Langhoff
2006-12-09 11:51 ` Jakub Narebski
2006-12-09 12:42 ` Jeff Garzik
2006-12-09 13:37 ` Jakub Narebski
2006-12-09 14:43 ` Jeff Garzik
2006-12-09 17:02 ` Jakub Narebski
2006-12-09 17:27 ` Jeff Garzik
2006-12-10 4:07 ` Martin Langhoff
2006-12-10 10:09 ` Jakub Narebski
2006-12-10 12:41 ` Jeff Garzik
2006-12-10 13:02 ` Jakub Narebski
2006-12-10 13:45 ` Jeff Garzik
2006-12-10 19:11 ` Jakub Narebski
2006-12-10 19:50 ` Linus Torvalds
2006-12-10 20:27 ` Jakub Narebski [this message]
2006-12-10 20:30 ` Linus Torvalds
2006-12-10 22:01 ` Martin Langhoff
2006-12-10 22:14 ` Jeff Garzik
2006-12-10 22:08 ` Jeff Garzik
2006-12-10 21:01 ` H. Peter Anvin
2006-12-10 22:05 ` Jeff Garzik
2006-12-10 22:59 ` Jakub Narebski
2006-12-11 2:16 ` Martin Langhoff
2006-12-11 8:59 ` Jakub Narebski
2006-12-11 10:18 ` Martin Langhoff
2006-12-09 18:04 ` Linus Torvalds
2006-12-09 18:30 ` H. Peter Anvin
2006-12-10 3:55 ` Martin Langhoff
2006-12-10 7:05 ` H. Peter Anvin
2006-12-12 21:19 ` Jakub Narebski
2006-12-09 7:56 ` Steven Grimm
2006-12-07 19:30 ` Linus Torvalds
2006-12-07 19:39 ` Shawn Pearce
2006-12-07 19:58 ` Linus Torvalds
2006-12-07 23:33 ` Michael K. Edwards
2006-12-07 19:58 ` H. Peter Anvin
2006-12-07 20:05 ` Junio C Hamano
2006-12-07 20:09 ` H. Peter Anvin
2006-12-07 22:11 ` Junio C Hamano
2006-12-08 9:43 ` Jakub Narebski
2006-12-11 3:40 linux
2006-12-11 9:30 ` Jakub Narebski
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=200612102127.05894.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=discard@dawes.za.net \
--cc=ftpadmin@kernel.org \
--cc=git@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=jeff@garzik.org \
--cc=martin.langhoff@gmail.com \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).