[JDEV] GZipping Jabber Messages

[Ben Schumacher]

Mike-

It is my understanding that DotGNU working group wanted to use this for
their project. In that case, it is entirely possible that they are sending
messages much larger than the size a "normal" (user-to-user) message would
be... however, I'm still with you. I'm not convinced that much would be
gained by gzipping a 5K SOAP packet, especially when you consider the
overhead caused on CPU/memory usage. I think it would definitely need some
sort of hash to verify data integrity. Hmm... still seems like it'd be an
interesting idea to toy with.

Which I guess isn't outside the range of what everybody else has already
been saying.

Ben


On Sun, 6 Jan 2002 mlin at mlin.net wrote:
> OK, I think this explains quite a bit, because even the uncompressed 
> bandwidth usage (200kb in 24 hours) is essentially negligible. At this 
> rate any appreciable amount of server bandwidth would have the capacity 
> for many millions of connections, and other factors (such as kernel 
> limitations, XML parsing, memory constraints) will limit server capacity 
> long before bandwidth becomes an issue. Therefore, adding compression in a 
> heavily strained server will actually decrease its capacity, because 
> internal resources (such as CPU time and memory) will be taken away to 
> save bandwidth, which is plentiful.
> 
> >From the cost perspective, at this rate of transfer, the cost for 
> bandwidth per user is also negligible. Consider that if bandwidth costs 
> $10/GB (this is a number from a web hosting provider, and is probably much 
> higher than one pays for an actual pipe), then supporting one million 
> concurrent users each transferring 200kb in 24 hours costs $2,000 or 0.2 
> cents per user. Certainly this figure decreases if your bandwidth usage 
> decreases, but either number is negligible when compared to the secondary 
> costs of supporting that many users.
> 
> The questions, then, are: (1) under what conditions is the bandwidth usage 
> for a client connection non-negligible? and  (2) can you achieve the same 
> high compression ratios under these conditions?
> 
> I hypothesize that the answer to question (1) will imply that the data 
> being exchanged with the client is very non-repetitive and thus 
> non-compressible compared to the 200kb that crossed in 24 hours, and so 
> the answer to (2) will be no. But I will have to look into it further.
> 
> -Mike
> 
> 
> 
> 
> 
> "Michael F. March" <march at indirect.com>
> Sent by: jdev-admin at jabber.org
> 01/06/2002 02:13 PM
> Please respond to jdev
> 
>  
>         To:     <jdev at jabber.org>
>         cc: 
>         Subject:        Re: [JDEV] GZipping Jabber Messages
> 
>  
> 
> More info:
> 
> I captured XML from a 24 hr Jabber session and the XML from
> that session was 179601 bytes and it compressed down to
> 6966 bytes.