# 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](https://docs.jfrog.com/administration/docs/log-files-location-and-naming), 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

```bash
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:

```text
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](/self-managed/deployment/sizing/#artifactory-sizing-templates-criteria). 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](https://docs.jfrog.com/administration/docs/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

1. Pick the [template](/self-managed/deployment/sizing/#artifactory-sizing-templates-criteria) that matches the load you expect, then go **one size up**.
2. After traffic is real, measure RPM for a week and scale down only if both peak and sustained stay well under the lower template.
3. Size [Xray](/self-managed/deployment/sizing/#xray-sizing-templates-criteria) 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](/self-managed/deployment/sizing/).