445041 - JSON output should be gzipped

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Tinderbox, enhancement)

Description

[u278084]

At 1.2M, the json file takes quite a bit of time to download over a slow connection. I think we should gzip the json so it is shrunk to more reasonable <90K and unzipped at the client side.

Comment 1

[Robert Helmer [:rhelmer]]

(In reply to comment #0)
> At 1.2M, the json file takes quite a bit of time to download over a slow
> connection. I think we should gzip the json so it is shrunk to more reasonable
> <90K and unzipped at the client side.

I agree, this should be easy to do. I used a re-served gzipped JSON file for the examples (which I got a copy of from people.m.o recently, I'll put these up soon) and it was much better/faster/etc. to just let the browser do the gunzipping.

Cesar, do you think that Tinderbox should bother having an uncompressed json.js around still, or just keep a gzipped copy? I guess changing it would break anyone depending on it, but I don't think we've made any assurances for stability of this...

Comment 2

[Robert Helmer [:rhelmer]]

Took a quick look at the code.

Hey cls, what do you think about this:

* always compress static json.js.gz
* for dynamic data:
** if accept-encoding header supports gzip return gzip
** else return uncompressed

Compress:Zlib isn't used like this anywhere in showbuilds.pl yet, but it looks like printing gzipped data should just work, and we could set the do_json page to json.js.gz ..

Any thoughts?

Comment 3

[u278084]

I like that solution because I wasn't sure if serving zipped json was supported across all browsers. I was thinking we have both compressed and uncompressed versions, if it didn't hurt.

Comment 4

[Robert Helmer [:rhelmer]]

(In reply to comment #3)
> I like that solution because I wasn't sure if serving zipped json was supported
> across all browsers. I was thinking we have both compressed and uncompressed
> versions, if it didn't hurt.

I find it hard to imagine a browser which supports JS but not gzip encoding :) Could be wrong though.

The problem with what I've proposed though is that json.js would not exist anymore, only json.js.gz .. if we really care we could make Apache do this check and decompress on server side if the user agent does not support gzip encoding. Then the URL would continue to be "http://tinderbox/.../json.js" which would be nice.

Comment 5

[cls]

Assuming that the static & dynamic pages are generated in the same fashion, then the propossal sounds fine.  For the dynamic pages, I'm assuming that you'd add the Aceept-encoding: gzip check directly to do_json()?

Comment 6

[Robert Helmer [:rhelmer]]

(In reply to comment #5)
> Assuming that the static & dynamic pages are generated in the same fashion,
> then the propossal sounds fine.  For the dynamic pages, I'm assuming that you'd
> add the Aceept-encoding: gzip check directly to do_json()?

Right. Ok I've got the code together, I need to set up a test environment again though and make sure it actually works. I'll try to get this done this week.

Comment 7

[Mike Taylor [:bear]]

We are triaging older bugs (to give context)...

Is this a duplicate of bug 390341 or a duplicate in feel/scope?

Can we mark this as closed or do you still have a use case for it?

Comment 8

[Robert Helmer [:rhelmer]]

(In reply to comment #7)
> We are triaging older bugs (to give context)...
> 
> Is this a duplicate of bug 390341 or a duplicate in feel/scope?
> 
> Can we mark this as closed or do you still have a use case for it?

It was worked around in a similar way (see bug 571085).

As with the other bug, it would be more efficient to have Tinderbox do this once when the file was uploaded rather than have Apache do it on every HTTP request.

At this point I think the efficiency gain would be minimal, certainly not the long-pole in terms of using the Tinderbox JSONish output (the size and complexity of dealing with the data in the browser is probably the more pressing issue now, not the transfer time).

I suggest WONTFIX on this one due to bug 571085 being closed.

Comment 9

[Robert Helmer [:rhelmer]]

I don't really plan on working on this, unless my assumption about the gain being minimal in comment #8 is wrong.