Federated Repository Best Practices

JFrog Artifactory Documentation
Products
JFrog Artifactory
Content Type
User Guide
ft:sourceType
Paligo

Setting up Federated repositories on JPDs in a multisite environment impacts your organization's network, servers, and databases. It takes careful consideration and planning to configure a Federation that makes efficient use of available resources and provides timely and accurate synchronization across all Federation members.

This is why JFrog recommends building your repository Federations in stages, with thorough evaluations conducted at each stage to verify your infrastructure is configured properly to handle the demands of running repository Federations.

JFrog recommends the following best practices when configuring your JPD for repository Federations:

  • Persisted queue age

    This setting determines the amount of time that events remain in the queue before they are purged. The default value is 3 days. This means that if there is a disconnection between two Federation members that lasts longer than 3 days, the older events are purged and can no longer be synchronized. You need to perform a Full Sync operation to re-establish the Federation, which can take a long time to perform.

    If you increase this value to more than 3 days, it can greatly increase the size of your database table, which in turn increases costs and affects performance (depending on the number of events generated by each site).

    This setting is configured per JPD using the property:

    artifactory.events.log.cleanup.age.of.entries.to.discard.days

    It should be set to the same value for each Federation member.

  • Number of metadata workers

    Artifactory uses an internal mechanism (referred to here as a 'worker') to send metadata events in bulk via parallel threads from the source JPD to other Federation members. Each thread is managed by a worker. Each thread can handle the events for one Federated repository at a time. The default value is calculated based on the number of cores in the CPU.

    In terms of the Federation, the number of threads required is dependent on the number of repositories that are updated at the same time and the frequency of those updates. If many repositories are updated frequently and at the same time, more threads might be required. A sufficiently powerful server (for example, 64-core) should provide sufficient power to manage 20-40 threads.

    To configure the number of metadata workers, set the following property in the artifactory.system.properties file (a restart is required):

    artifactory.persistentQueue.trigger.number.of.threads

    For more information, see Artifactory System Properties.Artifactory System Properties

  • Number of binary import workers

    Artifactory uses an internal mechanism (referred to here as a 'worker') to import binary events from the source JPD to the target Federation members. The default value is 6.

    In terms of the Federation, the number of workers required is dependent on the number of binaries the Federation is expected to handle, their relative size, and the capacity of your network. You need to find the correct balance between the amount of network bandwidth dedicated to importing binaries and the time it will take to import them.

    To configure the number of binary import workers, set the following property in binarystore.xml (under the Federated provider section):

    numberOfRemoteImporters

    Note

    For more information about binarystore.xml, see Binary Provider.Binary Provider

  • Number of thread executors

    Thread executors (also known as pools), which are located in the target Federation member, enable the metadata events sent from the source Federation member to be uploaded in parallel while maintaining the correct order of the files.

    Important

    The number of thread executors should always be equal to or greater than the number of metadata workers, otherwise a bottleneck will result.

    To configure the number of thread executors, set the property:

    artifactory.federated.mirror.events.bulk.max.pools

    For more information, see Configure Federated Repositories for Bulk Event Mirroring and Parallel Processing.

    Tip

    In addition to increasing the number of metadata workers and thread executors, you may need to increase the following timeout thresholds above their default values (2 min.) if you expect your Federations to carry heavy loads:

    • artifactory.federated.mirror.events.bulk.executor.poll.timeout.minutes

    • artifactory.federated.mirror.events.bulk.fullSync.executor.wait.timeout.minutes

    Increase these values in proportion to the maximum expected load. For more information about these settings, see Configure Federated Repositories for Bulk Event Mirroring and Parallel Processing.

  • Number of threads for each executor

    This setting determines how many metadata events for a particular repository can be processed in parallel while preserving the correct order (for example, for Docker events this means uploading all layouts followed by all manifests). This number can be increased by adding threads to each thread executor. The default value is 4.

    To configure the number of threads for each executor, set the property:

    artifactory.federated.mirror.events.bulk.threadsPerPool

    For more information, see Configure Federated Repositories for Bulk Event Mirroring and Parallel Processing.

  • Network infrastructure

    The capabilities of your organization's network are of paramount importance to the optimal functioning of your Federation. The stronger the network connections between the members and the greater the bandwidth, the better the Federation will be able to avoid latency when sending metadata events and binaries from site to site.