Issue Details (XML | Word | Printable)

Key: MBS-3168
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Dave Evans
Reporter: voiceinsideyou
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
MusicBrainz Server

Web Service responses could be compressed

Created: 04/Aug/11 04:50 PM   Updated: 21/Sep/11 09:16 PM   Resolved: 21/Sep/11 09:16 PM
Component/s: Admin, Web service
Affects Version/s: None
Fix Version/s: None

Issue Links:
Depends
 


 Description  « Hide

I can see that regular web requests are being compressed which is awesome! However WS requests do not seem to be, according to Firebug:

e.g. http://musicbrainz.org/ws/2/release/8e061dc4-790e-4587-ba53-011e7852f88d?inc=release-groups+media+recordings+puids+artist-credits+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels is 1.2MB

Firebug gives me the below (no "Content-Encoding gzip")

Date	Thu, 04 Aug 2011 16:47:10 GMT
Content-Type	application/xml; charset=utf-8
Connection	keep-alive
Keep-Alive	timeout=20
Server	nginx/0.7.65
Content-Length	1253068

with request (accepting gzip, deflate)

Request Headersview source
Host	musicbrainz.org
User-Agent	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Accept	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language	en-nz,en-au;q=0.8,en-gb;q=0.6,en;q=0.4,en-us;q=0.2
Accept-Encoding	gzip, deflate
Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection	keep-alive
Cookie	javascript=true; remember_login=SNIP; tracklist_mode=basic; musicbrainz_server_session=efb637a44ac74e90e23c11f34f483fd3cca22214

This is important for the links like above; MB's bandwidth to Singapore appears to be about 30-40kB/s so it would probably improve the speed of that request significantly.



Sort Order: Ascending order - Click to sort in descending order
Robert Kaye added a comment - 04/Aug/11 05:46 PM

Dave: I thought we had started compressing all of our traffic many moons ago. But, this makes sense since I never saw a drastic bandwidth drop I would expect from compressing the WS traffic.

To fix this, is this an MBS or MBH issue? Should you or ocharles look at it?


Robert Kaye added a comment - 05/Aug/11 06:55 AM

voice: djce added compression to test.musicbrainz.org. Can you please have a good play to make sure it doesn't break anything?


Dave Evans added a comment - 05/Aug/11 06:56 AM

gzipping should now be enabled for test.musicbrainz.org, only for content >1100 bytes long, and only for text/html and application/xml


voiceinsideyou added a comment - 05/Aug/11 08:13 AM

Thanks Dave/Rob!

I will do so properly (from Picard as well, to make sure it is sending Accept-gzip/deflate) this weekend, but a cursory test shows great performance improvement for us out in the badlands of the world

Anyone know if we should expect better bandwidth to SEA in general, or the 30-40kB/s is pretty normal?


voiceinsideyou added a comment - 06/Aug/11 04:46 AM

For me, it's an awesome improvement. With that nastiest of requests above

From browser: 49 secs -> 10 secs
From Picard 0.15.1: 47 secs -> 7 secs

Will test some earlier Picard versions on /ws/1 later (which I believe use different QT components for web requests, may or may not support gzip).


voiceinsideyou added a comment - 07/Aug/11 03:35 PM - edited

Works without issue for me on Picard 0.12.1 and Picard 0.14 (on Win7) whether or not it supports compression! Bit harderto detect any noticeable performance difference as I can't see a way to generate as nasty a request against /ws/1