Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: core
-
Labels:
-
Environment:Jenkins 2.204.1
Linux (Ubuntu 18.04)
OpenJDK 8u242
-
Similar Issues:
-
Released As:Jenkins 2.220
Description
With the new jenkins.model.StandardArtifactManager.disableTrafficCompression property (JENKINS-26008 / PR #4205), I was expecting improved performances when archiving artifacts from slaves to master. Especially when there is no room for further compression (when the artifact is already a compressed archive).
But my first tests with 2.204.1 and this option are disappointing. On my test setup:
- with traffic compression (default setting), archiving a ~200 MB .tar.gz file consistently takes ~50 seconds (which is really not great already)
- without traffic compression (the new option), it now takes ~240 seconds!
I suspect this is because FilePath.TarCompression.NONE lacks a layer of buffering input/output streams, which is there in FilePath.TarCompression.GZIP:
FilePath.java#L758
- GZIPInputStream is a buffering InputStream (here with buffer size set to 8K)
- GZIPOutputStream is a buffering OutputStream (with a default buffer size of 512), and there is also an additionnal BufferedOutputStream involved (with its default buffer size of 8K)
I will submit a PR for FilePath.TarCompression.NONE to add the missing buffering layer, so that the difference with GZIP will really be only about compression.
Tagging as a LTS candidate (for 2.204.3), to be considered after it is released in the next weekly. It's not a critical fix, but on the other hand the change is pretty simple, can hardly have any undesirable side effects, and is useful in some use cases.