mirrors/jgit - jgit - source @ dussan.org

177 Commits

49 Branches

Tree: c0f093899f

Commit Graph

Author	SHA1	Message	Date
Shawn O. Pearce	c0f093899f	http.server: Use TemporaryBuffer and compress some responses The HTTP server side code now uses the same approach that the smart HTTP client code uses when preparing a request body. The payload is streamed into a TemporaryBuffer of limited size. If the entire data fits, its compressed with gzip if the user agent supports that, and a Content-Length header is used to transmit the fixed length body to the peer. If however the data overflows the limited memory segment, its streamed uncompressed to the peer. One might initially think that larger contents which overflow the buffer should also be compressed, rather than sent raw, since they were deemed "large". But usually these larger contents are actually a pack file which has been already heavily compressed by Git specific routines. Trying to deflate that with gzip is probably going to take up more space, not less, so the compression overhead isn't worthwhile. This buffer and compress optimization helps repositories with a large number of references, as their text based advertisements compress well. For example jgit's own native repository currently requires 32,628 bytes for its full advertisement of 489 references. Most repositories have fewer references, and thus could compress their entire response in one buffer. Change-Id: I790609c9f763339e0a1db9172aa570e29af96f42 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	14 years ago

Author

SHA1

Message

Date

Shawn O. Pearce

c0f093899f

http.server: Use TemporaryBuffer and compress some responses

The HTTP server side code now uses the same approach that the smart
HTTP client code uses when preparing a request body.  The payload
is streamed into a TemporaryBuffer of limited size.  If the entire
data fits, its compressed with gzip if the user agent supports that,
and a Content-Length header is used to transmit the fixed length
body to the peer.  If however the data overflows the limited memory
segment, its streamed uncompressed to the peer.

One might initially think that larger contents which overflow
the buffer should also be compressed, rather than sent raw, since
they were deemed "large".  But usually these larger contents are
actually a pack file which has been already heavily compressed by
Git specific routines.  Trying to deflate that with gzip is probably
going to take up more space, not less, so the compression overhead
isn't worthwhile.

This buffer and compress optimization helps repositories with a
large number of references, as their text based advertisements
compress well. For example jgit's own native repository currently
requires 32,628 bytes for its full advertisement of 489 references.
Most repositories have fewer references, and thus could compress
their entire response in one buffer.

Change-Id: I790609c9f763339e0a1db9172aa570e29af96f42
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

14 years ago

1 Commits (c0f093899f8c027fb4e0f4418ac19b0f8ad6be16)