Add GzipConfig.compressionLevel #8059
Conversation
|
Looks like the builds failed for some weird reasons that appear mostly unrelated to the changes in this PR, with the exception of: [error] * method gzip(Int)akka.stream.scaladsl.Flow in object play.api.libs.streams.GzipFlow does not have a correspondent in current version And yes, the change isn't binary compatible, but it's source compatible - is that not enough? |
|
@jxtps maybe you should add exclusion rule to MiMa config to solve this compatibility problem |
|
I am not familiar with the MiMa config - what is that? Any chance you could make the change and we can get this merged? Thanks! |
There was a problem hiding this comment.
@jxtps If you add changes that break compatibility, you must add the relevant exclusion rules here: https://github.com/playframework/playframework/blob/master/framework/project/BuildSettings.scala#L172. The mimaReportBinaryIssues task gives you what you need to add: https://travis-ci.org/playframework/playframework/jobs/309864032#L970
The reason for this is to document the changes we've added and for what reason, so we can report which APIs are incompatible in Play 2.7.
|
Ok, I added the exclusions. Assuming that does the trick, I guess this is the part where you ask me to squash the commits? ;) |
|
Thanks for that, @jxtps. There is still a missing compatibility issue that needs a filter: https://travis-ci.org/playframework/playframework/jobs/312175914#L535-L536 |
|
Added. |
|
@jxtps "This branch has conflicts that must be resolved" - can you please rebase against latest |
Allow user to specify the compression level to use for the underlying Deflater instance.
Add BuildSettings exclusions to document the interface changes.
play.api.libs.streams.GzipFlow.gzip needed an exclusion.
|
Rebased. |
Allow user to specify the compression level to use for the underlying Deflater instance, and switch the default compression level from Deflater.BEST_COMPRESSION to Deflater.DEFAULT_COMPRESSION.
Mailing list discussion: https://groups.google.com/d/topic/play-framework/xjgcXPsRvyo/discussion
In a not very scientific microbenchmark where I compress a 600kb webpage 100x for each compression level I got the following (on the second run so things have had a chance to JIT):
[info] application - Level 1: 619,883 -> 111,773, 18.03130590772775%, nanos: 531,628,867, 11177300
[info] application - Level 2: 619,883 -> 87,209, 14.068622627173193%, nanos: 549,247,847, 8720900
[info] application - Level 3: 619,883 -> 94,679, 15.27368874448888%, nanos: 731,691,153, 9467900
[info] application - Level 4: 619,883 -> 84,454, 13.624183918578183%, nanos: 804,356,176, 8445400
[info] application - Level 5: 619,883 -> 81,712, 13.181842379932988%, nanos: 1,152,557,312, 8171200
[info] application - Level 6: 619,883 -> 57,972, 9.352087410043508%, nanos: 1,826,056,529, 5797200
[info] application - Level 7: 619,883 -> 58,539, 9.443556284008434%, nanos: 2,679,872,317, 5853900
[info] application - Level 8: 619,883 -> 56,608, 9.132045886078503%, nanos: 8,115,200,116, 5660800
[info] application - Level 9: 619,883 -> 56,413, 9.100588336831306%, nanos: 11,152,594,021, 5641300
Deflater.DEFAULT_COMPRESSION = -1 but corresponds to 6 in actual usage.