Closed Bug 585194 Opened 15 years ago Closed 14 years ago

Have tinderbox serve static logs with "Content-Type: text/plain" and "Content-Encoding: application/gzip" response headers

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cjones, Assigned: fox2mike)

References

Details

(Whiteboard: [needs confirm])

Right now they're served as "Content-Type: application/gzip", which means that if one wants to read the raw log, one has to download, gunzip it, then load it in a text editor. This is a fair amount of overhead, but oftentimes still faster than waiting for showlog.cgi. If the headers were set correctly, one could just remove the "showlog.cgi" bits from the tinderbox URLs linked from everywhere, and directly load the textual log in web browsers. I wrote a hacky patch to Firefox's HTTP code to munge these headers just for tinderbox.mozilla.org, and it works great. This is part of a bigger plan to have TBPL do all its parsing client-side.
Chris told me that this could make a significant difference in load, any chance someone can look at this soon?
Severity: normal → major
Assignee: server-ops → justdave
I asked Ben about pushing on this because I've gotten more frequeunt ISEs on loading logs in the last day. To be clear about load different, this bug alone would allow developers to conveniently bypass showlog.cgi to fetch logs, and fetching a static log should be close to free in terms of CPU cycles (at least compared to showlog.cgi). The long term goal is to parse logs on the client side, in TBPL. When we have that, there should definitely be a significant drop in load. With just this bug fixed, the drop in load will be proportional to the number of developers who choose to step around showlog.cgi, which I can't estimate offhand though I know of maybe 4 people who've wanted this for a long time. There may be others.
I tested this locally and I think the Apache settings are along the lines of: AddType text/plain gz AddCharset ASCII gz AddEncoding x-gzip gz I *think* that the only static .gz files inside the tree directories right now are the logs (they will look something like 1281421185.1281234504.1281239003.gz) so doing this for all of /tinderbox/*/ should be safe.
all of the static cached files (.txt, .js, .html panel, quickparse, etc) are in that directory, too, so we'll still have to limit it to gz files.
(In reply to comment #3) > AddCharset ASCII gz many of the logs actually contain UTF-8, though.
I filed bug 601313 for the same issue (plus one more) on the logs being served on ftp.mozilla.org.
I just added this to tinderbox-stage.mozilla.org, can someone verify and then I'll push it to prod?
Assignee: justdave → shyam
Alright, it works now : Before - trinity:~ shyam$ curl -I -L http://tinderbox-stage.mozilla.org/Firefox/1289373624.1289376709.405.gz HTTP/1.1 200 OK Date: Wed, 10 Nov 2010 08:35:00 GMT Server: Apache/2.2.3 (Red Hat) Last-Modified: Wed, 10 Nov 2010 08:12:05 GMT ETag: "18d74ae-1345e8-494ae69acdf40" Accept-Ranges: bytes Content-Length: 1263080 Content-Type: application/x-gzip Connection: close After : trinity:~ shyam$ curl -I -L http://tinderbox-stage.mozilla.org/Firefox/1289373624.1289376709.405.gz HTTP/1.1 200 OK Date: Wed, 10 Nov 2010 08:35:41 GMT Server: Apache/2.2.3 (Red Hat) Last-Modified: Wed, 10 Nov 2010 08:12:05 GMT ETag: "18d74ae-1345e8-494ae69acdf40" Accept-Ranges: bytes Content-Length: 1263080 Content-Type: text/plain; charset=ascii Content-Encoding: x-gzip Connection: close I can see logs in clear text in the browser (vs being asked to download the logs). Verify that other functionality isn't hosed and I'd be happy to push this fix over to production.
Whiteboard: [needs confirm]
I tried a few things on stage (loading other logs, starring, showlog.cgi) and it looks fine to me.
Alright, based on Gavin's comment..I've pushed this to tinderbox.m.o and verified on http://tinderbox.mozilla.org/Firefox/1289815404.1289819896.15016.gz
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.