Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a very typical scenario:

browser -> web server -> web service

I've seen lots of articles/documentation about the benefit of compressing the data sent from the web server to the browser to save bandwidth, but I'm wondering if there are similar benefits to compressing the data between the web service and the web server?

XML should compress very small, so of course we'd get the same benefits in terms of bandwidth, but I'm specifically wondering if that will be offset by the processing power needed on the web server, to decrypt the SOAP messages that it receives.

Has anyone enabled gzip for web services, and has there been any performance improvement?

For that matter, will web service clients even understand gzip in the first place? Or would enabling encryption be a waste of time, that would never never be taken advantage of by the web service client?

share|improve this question
1  
This probably would be get a better answers on stackoverflow –  Zoredache Sep 9 '09 at 21:31
    
I you are in doubt, you can start using a very low compression ratio, so you don't use too much cpu –  The Disintegrator Sep 10 '09 at 7:18
    
Yeah, I went back and forth in my head, trying to decide if stackoverflow or serverfault was the best place; in the end, I decided that it's probably more of a server setting than a coding issue, so I decided here, but I was never 100% sure. ;) –  sernaferna Sep 10 '09 at 12:14

4 Answers 4

Seeing as how gZip is handled by the users browser, the web client on the other end will need to be able to understand how to decompress gzip. You will be able to tell this by looking in the headers. IIRC it's the "accept" header, and you're looking for "gzip" and "deflate".

The encoding/decoding overhead for gzip is fairly nominal, however it is there. It's useful in browsers because the are not particularly timely - the user will just sit there getting irritated till the page has loaded. A web service is a bit different, they usually have to be pretty fast or else the whole application often appears to have hung.

The only time I would suggest gzip would be useful in a web service would be if it's a trivial service that is going to be hammered thousands of times a day, where the savings from 10kb to 2kb of XML would be worth the processing overheads. And that's assuming that the web service on the other end can accept gzip in the first place.

share|improve this answer

As you have stated, server sends headers as the content is zipped, and browser decrypts it.

If you want to do it between your web server and web service, since your service is NOT a browser, you'd read headers yourself (or assume everything iz gzipped) and you'd use gzipdecode before you send the request to SOAP handler.

Unless you do not transmit a lot of data back and forth (which is worth to compress) I don't see any benefit coming out of it. Even when beneficial compression wise, if you don't have enough CPU and RAM to support it, it can be fatal.

Hope it helps, D

share|improve this answer

BTW, remember that gzipping binary data CAN result in MORE information not less. So in any event, you'd have to be aware of the type of data being gzipped.

share|improve this answer
1  
Since it is SOAP data, it's xml formatted text. So, it should gzip well. –  sybreon Sep 10 '09 at 0:48

The question comes down to what does your server have to spare -- CPU or bandwidth? If you're constantly waiting for the network but your CPU is idle, then you probably should be looking into compression. If your CPU is busy but you're not sending much data, then compression probably isn't for you.

XML is a very verbose (and more importantly, repetitive) language, so compression will probably make a decent difference in the amount of data transmitted.

Compression is only useful if both sides support it, otherwise flipping the switch will do nothing. Advertising that you support compression makes very little difference if compression isn't ever actually used.

Finally, it's not necessarily all-or-nothing if you're the one transmitting. Gzip compression (LZ77) is tunable to optimize for speed, size, or something in between. How that tuning is done depends on your implementation, but only the side SENDING the data gets to decide. Decompressing gzip'ed data that is highly compressed takes no more resources than decompressing data that was only lightly compressed, so the recipient shouldn't care anyway.

share|improve this answer
    
@tylerl: I agree. And the question "what is the scarce resource, CPU or bandwith?" can probably be reduced to: Is the connection between the web server and backend web service a LAN link, or a WAN link? If you're on plain old gigabit ethernet, then I have never seen compression used, and can't imagine it would make sense. –  Jesper Mortensen Sep 9 '09 at 23:20
    
I agree and disagree. There is a difference between multi-national corp. sys-admin and ordinary people who wants to put up 3-5 servers together in a small company. We shouldn't advice a barcode reader to someone who has 5 products to sell, and he sells 5 products/day. At least we should put a note about it (ref: 'make a decent difference in the amount of data transmitted') –  Devrim Sep 10 '09 at 15:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.