-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins 2.204.1
Linux (Ubuntu 18.04)
OpenJDK 8u242
-
-
Jenkins 2.220
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.
[JENKINS-60907] Poor performance with jenkins.model.StandardArtifactManager.disableTrafficCompression=true
Description |
Original:
With the new {{jenkins.model.StandardArtifactManager.disableTrafficCompression}} property ( 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|https://github.com/jenkinsci/jenkins/blob/jenkins-2.204.1/core/src/main/java/hudson/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 here there is also an addition {{BufferedOutputStream}} involved (with its default buffer size of 8K) I will submit a PR for {{FilePath.TarCompression.NONE}} to add the missing buffering layer, such that the difference with {{GZIP}} will really only be about compression. |
New:
With the new {{jenkins.model.StandardArtifactManager.disableTrafficCompression}} property ( 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|https://github.com/jenkinsci/jenkins/blob/jenkins-2.204.1/core/src/main/java/hudson/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. |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Fixed but Unreleased [ 10203 ] |
Labels | New: lts-candidate performance |
Released As | New: https://jenkins.io/changelog/#v2.220 | |
Status | Original: Fixed but Unreleased [ 10203 ] | New: Resolved [ 5 ] |
Released As | Original: https://jenkins.io/changelog/#v2.220 | New: Jenkins 2.220 |
With buffered streams (PR #4459), my test case with traffic compression disabled now completes in ~30 seconds (vs. ~50 seconds with compression).