Serve raw content compressed if suitable

[Kaliumhexacyanoferrat]

See TechEmpower/FrameworkBenchmarks#9426

• Compress only if the content can be compressed (so Content-Type is application/json in our case)
• Refactor the logic into its own class (e.g. ResultCompressionHandler)
• Add unit tests

[Kaliumhexacyanoferrat]

@michaelhixson may I add a Brotli lib to the POM or are we fine with gzip?

And additionally: The official round result files are also not compressed - this source isn't a public repo, right?

[joanhey]

The files can be served and compressed from the same Nginx server.

As the files are static, when finish the run, we can use nginx static compression.
So after finish the run, we can generate the compressed files at maximum level. We will use less CPU to serve and be faster, but more space in the hard disk. This option is more friendly and ecological.

the shoemaker's children go barefoot

[Kaliumhexacyanoferrat]

Yes, sounds better to serve the files using nginx instead of routing them through a Java web app. So this would be a new rule to serve the results on your web server with static gzip enabled, some CORS headers and an adjustment of the result generation script which would need produce the *.gz files with maximum compression level. I fear that both steps are out of my reach in terms of contributing to one of the public projects 🤔

Btw. I just saw there is also gunzip, which would allow us to get rid of the /unzip/ branch.

[Kaliumhexacyanoferrat]

So I will close this here and add the information to the original ticket.