Skip to content
Notifications
Clear all

Has anyone else's Xray 4.x upgrade tanked their Artifactory performance?

1 Posts
1 Users
0 Reactions
3 Views
(@backend_perf_guru)
Estimable Member
Joined: 5 months ago
Posts: 155
Topic starter   [#7240]

We've been running JFrog Artifactory Enterprise with Xray for several years, monitoring security and license compliance across our multi-site replication topology. Our upgrade from Xray 3.x to 4.2.4 last month has been nothing short of a performance disaster, and I'm looking to see if our experience is an outlier or a systemic issue.

The primary symptom is a massive, consistent increase in Artifactory request latency, specifically for `GET` and `HEAD` requests on Docker layers and Maven artifacts, which are our most frequent operations. This degradation is most pronounced on our read-heavy edge nodes. Our pre-upgrade P99 latency for a simple `HEAD` request on a ~50MB Docker layer was consistently under 80ms. Post-upgrade, that same request now oscillates between 450ms and 1200ms, with frequent spikes correlated to Xray's internal scanning queue activity. This has directly impacted developer CI/CD pipelines and container startup times in our staging environments.

Our investigation points squarely at the integration layer and the new "asynchronous" scanning model. While Xray 4.x purports to decouple scanning from the download path, our Artifactory logs show a profusion of `Waiting for Xray Indexing` messages on requests that should be serving cached binary data. The performance hit suggests a blocking or semi-blocking check is still occurring, perhaps for metadata or a pre-flight scan status lookup, before the artifact can be served.

We've reviewed and tuned the documented parameters:
- `xray.gracefulStartupDelay` (increased to 180s)
- `xray.async.scan.numThreads` (adjusted relative to our core count)
- Artifactory's `xray.properties` connection timeouts and retries

The configuration appears sound, yet the latency persists. A packet capture during a high-latency request shows a rapid back-and-forth between Artifactory and the Xray service over the internal gRPC channel *before* the artifact stream begins, which was not the case in 3.x.

Has anyone else observed this fundamental shift in performance characteristics after upgrading to Xray 4.x? Specifically:
* A sustained 5x-10x increase in baseline Artifactory request latency?
* Increased load on the database layer (we're seeing more connections from the Xray service)?
* Any successful tuning parameters beyond the standard JFrog documentation that restored near-baseline performance?

We're currently considering a rollback, as the security benefits are negated by the operational impact. I'm hoping the community has deeper forensic data or perhaps a confirmed bug ticket we can reference.

--perf


--perf


   
Quote