extremely slow artifact uploads

[loomis]

We're currently experiencing a problem with boot 2.6.0+ where uploads for large artifacts take an extremely long time: 6.5 minutes for a 50 MB artifact. The same upload (same client, same server) only takes 30 seconds with boot v2.5.5, leinigen 2.7.1, and maven 3.3.9.

Although there are significant changes to the "deploy" code in boot.aether between boot 2.5.5 and 2.6.0, nothing jumps out as a obvious cause of this.

However when looking at the debug output for the upload with boot 2.6.0, one possible cause might be a change in the default buffer size. The progress transfer events show:

 :data-buffer
 #object[java.nio.HeapByteBufferR 0x661a95ce "java.nio.HeapByteBufferR[pos=0 lim=2048 cap=2048]"],
 :data-length 2048,

indicating a buffer size of 2K. Downloads (uploads aren't instrumented) with boot 2.5.5 shows a buffer size of 4K. The buffer size and other default transfer do not appear to be set explicitly anywhere in the boot code.

[Deraen]

Are you deploying to clojars? If so, try using canonical deploy url https://clojars.org/repo instead of new CDN https://repo.clojars.org.

[loomis]

No, we're deploying to a private nexus server. Although I could test other repositories, I don't think the issue is on that end given that leiningen and maven upload speeds are normal.

[Deraen]

Okay.

I don't think the issue is on that end given that leiningen and maven upload speeds are normal.

Leiningen automatically uses the canonical deploy url for deploys and cdn for downloads, only Boot uses CDN for both. But probably this issue is caused by something else.

[loomis]

The problem was an expensive evaluation of a debugging argument for all calls of the transfer-listener function. This was added to artifact uploads in boot 2.6.0. The timings of uploads for a large uberjar are:

• 2.5.5 = 1' 1"
• 2.6.1 = 8' 13"
• 2.7.1 = 8' 45"
• 2.7.1-patched = 1' 10' (no -v option)

With the patched version and a -v option, the debugging is printed, which then results in the same slow upload time.

[arichiardi]

You have probably done it already but check #558.

[loomis]

@arichiardi Yes, looked at it. The important change for us is moving from a function to a macro for the transfer-listener debugging to fix the network throughput. Changing from debug to trace level is probably also a good idea, but I don't have a strong opinion there. Getting either PR into a release soon would be helpful, as we're now having to look at workarounds (revert to 2.5.5, distribute modified boot, ...) to make our CI system responsive again.

[loomis]

Fix to be done with #558.

[alandipert]

Fixed via #558