Closed Bug 816164 Opened 9 years ago Closed 9 years ago

gzip-compress crash report submission on Android

Categories

(Toolkit :: Crash Reporting, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla20

People

(Reporter: kairo, Assigned: kats)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

We should gzip-compress the crash report submissions on Android, e.g. to make timeouts less likely over slow mobile data connections and reduce costs for people paying for that traffic.

We should just send the whole POST request with gzip compression to do this, so it will reduce the size of both the minidumps and the annotations (including e.g. the logcat stuff being added in bug 815684).
We will need to do some testing to make sure our server side understands this, but I'm told that Apache will probably just internally decompress the request and the collector will probably not even notice the difference. Still, testing is better than assuming. ;-)

See bug 781630 for more details.
This shouldn't be very complicated, I can take it.
Assignee: nobody → bugmail.mozilla
Blocks: 815684
Note that per comment 0 we don't know that the server side of things will work correctly with this, so once you get a patch together we'll need to do some testing.
Is there a test server I can test against? I don't want to be hammering away at the actual crash-stats server.
Attached patch Patch (obsolete) — Splinter Review
I haz a patch. It compiles but has not been tested yet. According to http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#input mod_deflate is required and needs to be set as an input filter on the server for this to work.
Depends on: 816302
I verified that using this patch, the data that gets sent out seems correct. I tested by having Fennec submit to my EC2 instance where I had netcat listening for the data and dumping it to a file. After stripping out the HTTP headers the remaining data was a valid gzip stream and could be run through gunzip without errors. Also I noticed that the Content-Length header on the HTTP connection matched the length of the compressed data stream. I'm not sure if that is correct or not, but if necessary I can change it to be the length of the uncompressed data stream instead.

Waiting on bug 816302 to get resolved so that we can test this against some actual crash-stats servers.
Attached patch PatchSplinter Review
Updated with a info log that I was using for debugging but that would be good to put in permanently.
Attachment #686246 - Attachment is obsolete: true
Depends on: 818682
Comment on attachment 686637 [details] [diff] [review]
Patch

The server side changes are done now; the collectors at crash-reports.mozilla.com have been updated to accept GZIP post data. I have a test submission at https://crash-stats.mozilla.com/report/index/bp-0b135cf8-2c29-402b-9056-7ee632121213 that was submitted from a device with this patch.

Requesting review now that we are ready to land this.
Attachment #686637 - Flags: review?(cpeterson)
Comment on attachment 686637 [details] [diff] [review]
Patch

Review of attachment 686637 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. How much did gzip reduce the crash report size?
Attachment #686637 - Flags: review?(cpeterson) → review+
In the submission that I measured, the body of the HTTP request went down from 317845 bytes to 61139 bytes.

Landed on inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/795545029135
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10)
> In the submission that I measured, the body of the HTTP request went down
> from 317845 bytes to 61139 bytes.

:D
https://hg.mozilla.org/mozilla-central/rev/795545029135
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
You need to log in before you can comment on or make changes to this bug.