Bitbucket Server Tomcat thread pool configuration for concurrent REST API load

Goal: reduce latency spikes observed when many concurrent users request pull‑request lists via the Bitbucket REST API by sizing the underlying Tomcat HTTP thread pool appropriately.

Constraint: the pool’s maxThreads and acceptCount are not configurable through the Bitbucket UI or server.properties; they must be set in server.xml, which requires a restart and can be overwritten during upgrades unless placed in /shared. Additionally, increasing the pool without sufficient heap or CPU can cause out‑of‑memory errors or GC pauses, and there is no built‑in autoscaling mechanism.

Uncertainty: what numeric values provide the best trade‑off for a given hardware profile, how to persist the custom server.xml across upgrades safely, and which JMX metrics indicate the pool is nearing saturation.

What maxThreads and acceptCount values minimize 95th‑percentile latency for a typical 2‑core, 8 GB JVM under 150 concurrent pull‑request list requests?

How can the edited server.xml be placed in /shared to survive upgrades without manual re‑application?

Which JMX attributes (e.g., queue length, active threads) should trigger an alert that the Tomcat thread pool is saturated?