Proxy repositories use caching to improve build performance. The settings you can use to configure caching are described in this article.
Cache Settings
Caching is configured in the settings of each proxy repository.
Maximum component age
This setting controls whether a client request will cause the proxy to check for changes to previously cached components on the remote repository being proxied. In most cases, components are considered immutable and will not change, in which case this value can be set to -1 to disable checking the remote repository for redeployed components. For a docker proxy repository, a component would usually be a tagged image, so the default max component age is set to 1440 minutes. If the repository being proxied allows redeploy of existing components then you should configure the proxy to check for updates periodically. If a client requests a component that already exists in proxy cache and the maximum component age has expired, the proxy will check whether this version of the component has been redeployed on the remote.
Maximum metadata age
The cache stores metadata about the versions of components available in the remote repository. When a client requests a version of a component not already cached and the metadata max age has expired, Nexus Repository will ask the remote what versions are available for the component. If the requested version is included in the updated metadata then the new version of the component can be retrieved from the remote to the proxy. A value of -1 will prevent the proxy from ever checking for new versions, which in most cases is not desirable. A value of 0 will always check for new versions.
Negative Cache (Not Found Cache)
When a client requests a component that is not yet stored in the proxy repository, a request is made to the remote repository being proxied. If the proxy repository Negative Cache is enabled and the remote repository response indicates that the component was not found, then the proxy repository caches a record of that event. Subsequent requests for the identical component will not result in a request to the remote repository until the number of minutes set by the Not Found Cache TTL (Time to Live) have elapsed. Performance is improved by reducing unnecessary round trips to the remote repository.
Invalidate Cache
When the cache is invalidated, the maximum metadata age and maximum component age values for components are expired. The next request for a component will cause a proxy repository to query the remote repository to obtain metadata for available versions of the component. Components previously downloaded to the proxy repository are not deleted from storage, so they will not be retrieved again from the remote if they have not changed. Invalidating cache also purges the contents of the not found cache.
You can invalidate cache for individual proxy repositories or for a group. Invalidating cache for a group impacts all the proxy repositories in the group. Since invalidating cache results in extra queries to the remote repository, targeting specific repositories is better for performance.
What Values Should I Use?
As with many performance related configuration settings, the answer to this question depends on your use case. Here are a couple of examples.
Proxy of a local hosted maven releases repository
For proxy repositories of an internal repository on your network that is updated frequently you should set the 'Maximum metadata age' cache timeout to be quite low. Assuming that the local network is fast, frequent updates should have less performance impact. A value of 0 will ensure that new versions are always found. If the releases repository does not allow republishing you should set the 'Maximum component age' to -1.
Proxy of a remote maven releases repository
Maven artifacts should not change so the 'Maximum component age' should be set to -1 to avoid unnecessary requests to the remote server. The 'Maximum metadata age' default value of 1440 ensures that new version information is updated daily.