[jira] [Resolved] (KAFKA-6430) Improve Kafka GZip compression performance

2018-02-16 Thread Ismael Juma (JIRA)
[ https://issues.apache.org/jira/browse/KAFKA-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma resolved KAFKA-6430. Resolution: Fixed Fix Version/s: 1.1.0 > Improve Kafka GZip compression performa

[jira] [Created] (KAFKA-6430) Improve Kafka GZip compression performance

2018-01-07 Thread Ying Zheng (JIRA)
Ying Zheng created KAFKA-6430: - Summary: Improve Kafka GZip compression performance Key: KAFKA-6430 URL: https://issues.apache.org/jira/browse/KAFKA-6430 Project: Kafka Issue Type: Improvement

Re: compression performance

2013-08-16 Thread Jan Kotek
ry mapped files. Not sure how it applies to this case. Regards, Jan Kotek On Friday 02 August 2013 22:19:34 Jay Kreps wrote: > Chris commented in another thread about the poor compression performance in > 0.8, even with snappy. > > Indeed if I run the linear log write throughput te

Re: compression performance

2013-08-15 Thread Jay Kreps
on that offsets increments continuously. Two > > >workarounds of this issue: > > > > > >1) In log compaction, instead of deleting the to-be-deleted-message just > > >setting its payload to null but keep its header and hence keeping its > slot > > >in the

Re: compression performance

2013-08-15 Thread Chris Hogue
gt;the logical offset of messages, write the deltas of their offset compared > >with the offset of the wrapper message. So -1 would mean continuously > >decrementing from the wrapper message offset, and -2/3/... would be > >skipping holes in side the compressed message. >

Re: compression performance

2013-08-15 Thread Sriram Subramanian
er message offset, and -2/3/... would be >skipping holes in side the compressed message. > > >On Fri, Aug 2, 2013 at 10:19 PM, Jay Kreps wrote: > >> Chris commented in another thread about the poor compression performance >> in 0.8, even with snappy. >> >> Inde

Re: compression performance

2013-08-15 Thread Jay Kreps
the wrapper message offset, and -2/3/... would be skipping holes in side the compressed message. On Fri, Aug 2, 2013 at 10:19 PM, Jay Kreps wrote: > Chris commented in another thread about the poor compression performance > in 0.8, even with snappy. > > Indeed if I run the line

compression performance

2013-08-02 Thread Jay Kreps
Chris commented in another thread about the poor compression performance in 0.8, even with snappy. Indeed if I run the linear log write throughput test on my laptop I see 75MB/sec with no compression and 17MB/sec with snappy. This is a little surprising as snappy claims 200MB round-trip