Measuring Requests Per Minute

Why measure

Artifactory sizing templates are keyed on requests per minute (RPM) and concurrent connections. RPM is the total number of HTTP requests handled by all Artifactory nodes in one minute. Concurrent connections are the HTTP threads serving those requests at one moment.

If you do not have these numbers, do not guess from user count. Count them from an existing Artifactory, or start one template larger and re-measure after go-live.

This page is a starting method. It uses the Artifactory request log, which lists every HTTP request the service handled.

Recommended method: request log

On each Artifactory node, open artifactory-request.log. Default location is $JFROG_HOME/artifactory/var/log/artifactory-request.log. In Kubernetes, exec into each Artifactory pod or collect the same file through your log stack.

Each line is pipe-separated. The first field is a UTC timestamp; the sixth is the request URL:

2018-11-18T15:39:04.902Z|d5d75b3c41242768|127.0.0.1|anonymous|GET|api/v1/cert/root|200|0|6|0|JFrog Access Java Client/4.1.12

1. Count requests per minute on one node

awk -F'|' '
  $1 ~ /^[0-9]{4}-/ && $6 !~ /system\/(ping|liveness|readiness)/ {
    minute = substr($1, 1, 16)
    count[minute]++
  }
  END {
    for (m in count) printf "%s %d\n", m, count[m]
  }
' artifactory-request.log | sort -k2 -n

The last lines are your busiest minutes on that node. Use at least several days of logs, including CI peaks.

The command skips liveness, readiness, and ping URLs. Those probes run constantly and inflate RPM without representing user or CI load.

2. Sum every Artifactory node

RPM in the sizing table is cluster-wide. Run the same command on each node (or each day’s archived log), then add the counts for the same UTC minute. The highest summed minute is your peak RPM.

If logs are already aggregated, filter to Artifactory request events only, group by minute, and sum.

3. Peak vs a typical busy minute

Peak is the single highest minute you observed.
Sustained is a typical busy minute, for example the 95th percentile of per-minute counts over a week.

If the peak is a rare spike and sits close to the next template, size for sustained load and watch that minute. If peaks are regular (hourly CI, release trains), size for peak.

4. Estimate concurrent connections from the same log

The tenth field is request duration in milliseconds. For the peak minute:

concurrent connections ≈ RPM × (average duration in seconds) / 60

Example: 20,000 requests in a minute with a 150 ms average duration is about 20000 × 0.15 / 60 ≈ 50 concurrent connections.

Compare both numbers to the Artifactory sizing table. If RPM and concurrency point at different templates, take the larger one.

Other sources

Use these when request logs are not available. They are less precise than artifactory-request.log.

Source	How	Notes
Ingress or load balancer	Requests per minute from nginx, the cloud load balancer, or the Kubernetes ingress controller, summed across backends	Includes health checks unless you filter them. Closest to client-visible RPM
JFrog Router metrics	Counter `jfrou_traefik_entrypoint_requests_total` from `/router/api/v1/metrics`. Rate × 60 is requests per minute. See Open Metrics to enable the feature and for endpoint and metric details	Platform entry-point traffic, not Artifactory-only. Useful as a cross-check

Do not use outbound connection gauges (for example jfrt_http_connections_*) as RPM. Those are remote-repository pools, not inbound request rate.

If you cannot measure yet

Pick the template that matches the load you expect, then go one size up.
After traffic is real, measure RPM for a week and scale down only if both peak and sustained stay well under the lower template.
Size Xray on indexed artifacts and daily scan volume. It can need a larger template than Artifactory.

Then apply the matching Helm sizing file and cloud infrastructure tables under Sizing.