-1

We are using Nexus as a maven mirror within the organisation to reduce the external network traffic and save builds from failing when some external repositories are down.

There are many different projects in the infrastructure, and many of them need some specific artifact from some specific repository, for example ZK, jaspersoft.

There are 2 strategies that we consider:

  1. using Nexus as the mirror for the 'standard' repositories, like central, spring, sonatype, and add external repositories to the POMs of the project, that need them (accepting some builds will fail if some of that repositories will become unavailable)

  2. adding all repositories that are used by at least one of the projects to the central nexus, which means, there will be a lot of repositories configured in nexus (about 50).

Is there any performance impact that we should expect from the 2nd strategy?

9ilsdx 9rvj 0lo
  • 7,955
  • 10
  • 38
  • 77
  • Go for option 2 (do not use option 1 that will be a mess). Option 2 is a clean solution. Second define the appropriate repos in your nexus and define a single group which is accessed by all (consumers). Second take a look if you can use routes to define particular repos which serve only specific artifacts. – khmarbaise May 05 '21 at 07:36
  • `about 50` <= I'm currently running nexus with more than 800 repos combining maven, docker, npm, apt, yum, ruby, nugget, pipy.... formats and for proxy, hosted and group repos, with about 1.5Tb of total blobstore content. The VM holding this has 4 vcpus and 16Go of Ram. Our current concern is data volume growth and definitely not performance. We are using the OSS version for now. Option 2 validated ! :) – Zeitounator May 07 '21 at 21:42

1 Answers1

2

The second strategy is the clean strategy.

Usually, this does not cause performance problems because you mainly read from the cache.

If, though, there is a very slow repository in the list, this might slow down operations which search for the latest version of an artifact.

But if you really experience performance problems with strategy 2, I would not use strategy 1 -- instead I would define different repository groups in Nexus for different purposes.

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142