community-build: Very slow updates when running community build locally
When running the community build locally I see very long (>= 10 mins) pauses coinciding with log output of the form,
[fs2] [info] Updating {file:/home/miles/projects/community-builds/target-0.9.5/project-builds/fs2-5a963db814460240b52e63b349e38ac1d658a6a7/project/}fs2-5a963db814460240b52e63b349
which I believe corresponds to an sbt update in the project about to be built. During these pauses I can see that the community build process is blocked on a socket read from,
java 7165 miles 70u IPv4 4172377 0t0 TCP tarski.home:38968->ec2-54-67-111-226.us-west-1.compute.amazonaws.com:https (ESTABLISHED)
which corresponds to https://scala-ci.typesafe.com/. Is it possible that this machine is seriously overloaded? Or that it has limited connectivity with Europe?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 50 (30 by maintainers)
Commits related to this issue
- downgrade to sbt 0.13.12 because of the performance regression under investigation at https://github.com/scala/community-builds/issues/408 — committed to SethTisue/community-build by SethTisue 8 years ago
Probably, since that’s what I have in my local config — a single virtual repository, with two entries in my
~/.sbt/repositories
, one for Maven-style access and one for Ivy-style access. So I assume the scala-ci Artifactory could be set up the same way. I’d have to ask Adriaan if there were specific reasons he set it up the way he did, or if he was just fumbling around. (“Fumbling around” is how I would describe my own engagement with this, I have little real understanding of what I’m doing.)I haven’t done a cold timing recently, but 3.5 hours sounds very good — faster than it runs on Jenkins.
I did some work on this over the weekend — starting with a fresh local Artifactory config with only Maven Central, and then:
That, in combination with a nice long “Metadata Retrieval Cache Period” on all resolvers, seems to have fixed my own performance problems to my own satisfaction.
This is a little different than what Miles did, where his local Artifactory just retrieves everything from the Artifactory on scala-ci.
I took a different approach because my goal is for my new config to eventually replace the one on scala-ci, and hopefully that will result in improved performance for everybody, including our Jenkins runs, and people who are running locally using our Artifactory, and people like Miles who have a local Artifactory that points to ours.
But in order to make that happen, I’d have to upgrade the scala-ci Artifactory to a newer version, otherwise the XML config doesn’t carry over (and I don’t want to keep multiple versions in sync by hand). So, leaving this ticket open, but it is now fixed at least to the extent that:
I plan to return to this in 2017.