nullreference

Placing Compute Along the Database Request Path

2026-09-26T00:00:00+00:00

Where should a web request run when the host closest to the client is not the host closest to its data? Conventional routing can minimize client-to-compute delay. A database-backed request can also pay for each serial network wait between compute and the database. This paper tests whether a request-aware placement rule can reduce total response time.

The test runs one Rails service on two application compute nodes and uses a separate PostgreSQL node. It supports a narrow claim: for this service, requests with more serial database calls benefited from database-aware placement over user-first routing. The experiment does not test a general scheduler or other dependency types.

For a candidate compute host c, the measured score is:

estimated_latency(c) = client_to_compute_path(c) + N_serial × PostgreSQL_RTT(c) + route_residual(c)

N_serial counts database calls that depend on earlier calls. Parallel calls do not each add a full RTT to the critical path.

The network-only policy omits route_residual. The profiled policy estimates it from the route's measured zero-query cost. This is a practical model of the measured path. It is not a general model of CPU cost, queues, or every service dependency. The experiment found no measurable placement benefit from profiling over the simpler network-only policy.

I calibrated a route-aware cost model on Compute A and Compute B. I then changed the client-to-compute network path and tested the model on new requests. It predicted four direct-node medians within 0.08 to 0.33 ms. The three-query route was faster on Compute A. The 12-query N+1 route was faster on Compute B.

The routing proxy reduced the N+1 route median from 6.356 ms with user-first routing to 5.690 ms with the profiled policy. This is a 10.5% reduction across 500 requests per policy. The 95% bootstrap interval for the median change was 0.522 to 0.780 ms lower. The profiled policy and simpler network-only policy chose the same hosts. Their median difference was not measurable in this run.

The data guide defines the public role labels and measurement files.

Prototype and cost model

The prototype has a Python HTTP proxy and a placement planner. The same Rails service ran on both compute nodes. PostgreSQL ran on a separate database node. The app and database did not share a node. Both policies used the same strong-read primary. The proxy tested compute selection, not replica placement.

The network-only policy estimates response time as:

user_to_compute_RTT + sequential_query_count × SQL_round_trip_time

The profiled policy adds a route-specific residual for each compute host:

profiled_cost = user_request_path + host_route_residual + sequential_query_count × SQL_round_trip_time

I measured each host's /health request path and each Rails route. I measured the median time for SELECT 1 from each app host. The route residual is the direct route median minus the health request median and the sequential query count multiplied by the SELECT 1 median. This residual captures route work that the network-only score does not model. It does not isolate CPU time.

The /feed route makes three sequential SQL calls. The /feed-naive route makes one account call, one article call, and ten feedback calls. The seeded account has ten articles, so the N+1 route makes twelve calls.

Calibration and held-out test

I calibrated the model without added user-path delay. For each host and route, I warmed the endpoint 20 times and measured 500 requests. I measured 500 SELECT 1 calls after 20 warmups. The median SQL call times were 0.355 ms from Compute A to the database node primary and 0.231 ms from Compute B to the primary.

The test added 0.25 ms of one-way egress delay on the path from Compute B to Compute A. The new client-to-compute TCP connect medians were 0.088 ms for Compute A and 0.601 ms for Compute B. The /health request medians were 0.741 ms and 1.480 ms. I then measured 500 new requests for each route on each host. The calibration data and held-out direct measurements include all samples.

Route	Compute node	Profiled estimate	Held-out p50	Error
`/feed`	Compute A	2.261 ms	2.338 ms	0.077 ms
`/feed`	Compute B	2.451 ms	2.571 ms	0.120 ms
`/feed-naive`	Compute A	5.650 ms	5.978 ms	0.328 ms
`/feed-naive`	Compute B	4.449 ms	4.744 ms	0.295 ms

The profile chose the compute node with the lower held-out p50 for each route. These estimates use a single calibration run. They do not show that the profile will remain accurate under load or across other machines.

Routed results

The proxy opened a new upstream connection for each request. It warmed each policy and route 15 times. It then sent 500 requests for each of three policies and two routes. The run interleaved and randomized requests. All 3,000 requests returned HTTP 200.

Route	User-first p50	Network-only p50	Profiled p50	Selected host
Three-query `/feed`	2.834 ms	2.816 ms	2.829 ms	Compute A
Twelve-call `/feed-naive`	6.356 ms	5.742 ms	5.690 ms	Compute B

Both database-aware policies kept /feed on Compute A. Neither changed its median by a measurable amount. For /feed-naive, network-only routing lowered p50 by 0.614 ms relative to user-first routing. Profiled routing lowered p50 by 0.665 ms. The 95% bootstrap interval for the profiled change was 0.522 to 0.780 ms lower.

The profile did not improve the placement choice over the network-only policy. Both policies selected the same host for each route. Their /feed-naive p50 difference was 0.052 ms, with a 95% bootstrap interval from 0.191 ms lower to 0.137 ms higher. This test shows that route and host profiles can predict end-to-end cost. It does not show that the added profile logic improves routing when the simpler policy already chooses well.

The first proxy run used only the network score. It predicted a larger gain than the measured result. The initial run data records that result. The later profile reduced prediction error, but did not produce a measurable gain over network-only routing.

A deliberate policy disagreement

The first proxy experiment did not make the network-only and profiled policies choose different hosts. I added a controlled Rails route that runs N serial SELECT 1 calls. Compute A and Compute B are the two application nodes. PostgreSQL stayed on the separate database node. The same client sent requests to both application nodes.

I swept N = 0, 1, 3, 6, 12, 24, and 48. The network model used the measured /health path plus N times the per-query database time. The profiled model used the measured zero-query route plus N times the per-query database time. On the first calibration, the network model's predicted crossover was after 3.55 calls. The profiled model predicted it after 1.62 calls. The primary calibration records the inputs.

Serial calls	Compute A p50	Compute B p50
0	1.044 ms	1.499 ms
1	1.668 ms	1.844 ms
3	2.603 ms	2.443 ms
6	3.956 ms	3.225 ms
12	6.668 ms	4.555 ms
24	12.039 ms	7.405 ms
48	22.435 ms	12.743 ms

The network model chose Compute A at zero, one, and three calls, then chose Compute B from six calls on. The profiled model switched to Compute B at three calls.

At three calls, Compute B was 0.161 ms faster than Compute A. The 95% bootstrap interval for Compute A p50 minus Compute B p50 was 0.046 to 0.260 ms. At one call, Compute A was faster by 0.176 ms, with an interval from -0.246 to -0.115 ms. The raw sweep and summary include all samples. A 500-sample follow-up at two calls found no clear winner. Compute A was faster by 0.006 ms, with a 95% interval from -0.075 to 0.048 ms. The two-call follow-up is available. The data place the measured crossover between one and three calls, but do not locate it more precisely.

I repeated the direct comparison with a fresh calibration. The new network and profiled models both chose Compute A at one call and Compute B at three and twelve calls. Compute B was faster at three calls by 0.243 ms, with a 95% interval from 0.178 to 0.314 ms. This repeat supports a workload-dependent placement change. It does not show that the profiled model improves on the simpler network model. The measured host paths varied enough to move the predicted crossover. The repeat calibration, measurements, and summary are available.

I then sent requests through all three local proxies, using the fresh calibration. The same client sent one-call, three-call, and twelve-call requests. User-first routing kept all requests on Compute A. The two database- aware policies sent the one-call request to Compute A and the longer requests to Compute B.

Calls	User-first p50	Profiled p50
1	1.978 ms	1.966 ms
3	2.949 ms	2.865 ms
12	6.776 ms	4.918 ms

Profiled routing reduced the three-call p50 by 0.083 ms relative to user-first routing. Its 95% interval was 0.010 to 0.187 ms. At twelve calls, it reduced p50 by 1.858 ms, with an interval from 1.616 to 2.050 ms. Profiled routing did not measurably beat network-only routing. Their median difference was 0.022 ms at three calls, with an interval from -0.056 to 0.100 ms, and 0.059 ms at twelve calls, with an interval from -0.230 to 0.289 ms. The proxy samples and summary contain these measurements. Network-only p50 was 1.973 ms, 2.887 ms, and 4.977 ms at one, three, and twelve calls. The two database-aware policies chose the same host at each count in this repeated run.

This test supports route-dependent database-aware placement over user-first placement for this Rails service. It does not establish a benefit from profiling over a simpler policy that combines measured client-path and database costs. The sweep, proxy, measurement script, and Rails route are published with the data.

Isolation and limits

The application and database ran on separate nodes. The experiment did not test hostile tenants, a hardened sandbox, or failure isolation. It used one database primary, so it did not test compute and replica selection together.

This test used one Rails service, two application nodes, one database node, one client path, and one controlled delay. It did not model concurrent arrivals, queueing, failures, migration, or production traffic. The measured route split supports selective compute placement for this workload. It does not establish a production scheduler benefit.

The general scheduling question extends beyond PostgreSQL. A request can depend on several services, and each serial wait can affect the best compute location. This experiment did not measure Redis, object storage, or service-to-service calls. Future work can test a placement score that includes those dependencies and host compute cost.

Latency-aware placement and compute-data colocation have substantial prior work. NoMora uses measured application performance and network delay to place or move tasks. LambdaStore colocates serverless functions with storage. User-aware edge placement includes user latency in service placement. Corral jointly places compute and data while isolating jobs. This prototype does not claim that these broad ideas are new.

Sub-Millisecond Database RTT in Web Applications

2026-09-26T00:00:00+00:00

At a configured 0.75 ms database round-trip time (RTT), four ordinary three-query routes gained 2.2 to 2.6 ms. A 12-query Rails route gained 9.6 ms. A Redmine API workload gained 32.2 ms, and an Aimeos storefront workload gained 34.4 ms.

The effect remained visible below 1 ms. Its size depended on the database work in each request. These tests ran in local containers on one DGX GB10 host. They did not use a cloud.

Framework routes

Each framework used the same feed route. It looked up a reader, selected articles, and counted feedback. Each query used the result from the previous query, so the route made three sequential database calls. The raw Axum route prepared each query on each request. The cached Axum route reused prepared statements.

Go with database/sql and pgx: 0.91 ms at 0 ms, 3.40 ms at 0.75 ms. Change: +2.49 ms [2.29, 2.63].
Node.js with pg: 1.45 ms at 0 ms, 3.64 ms at 0.75 ms. Change: +2.19 ms [2.06, 2.52].
Rails with Active Record: 1.90 ms at 0 ms, 4.16 ms at 0.75 ms. Change: +2.26 ms [1.97, 2.47].
Axum with cached statements: 0.83 ms at 0 ms, 3.40 ms at 0.75 ms. Change: +2.57 ms [2.22, 2.70].
Axum with raw query strings: 1.21 ms at 0 ms, 6.32 ms at 0.75 ms. Change: +5.11 ms [4.82, 5.48].

The three-query routes gained about the 2.25 ms predicted by three sequential waits at 0.75 ms each. The raw Axum route gained more because it also prepared statements. The cached route stayed near the other three-query routes. This compares complete runtime and driver stacks. It does not isolate language speed.

The normal Rails route used three calls. A second route used one feedback count for each of ten articles. It made 12 sequential calls in total.

Grouped feedback counts, 3 calls: 1.90 ms at 0 ms, 4.16 ms at 0.75 ms. Change: +2.26 ms [1.97, 2.47].
One feedback count per article, 12 calls: 3.54 ms at 0 ms, 13.09 ms at 0.75 ms. Change: +9.55 ms [9.26, 10.40].

The 12-call route gained close to the 9 ms predicted by 12 sequential waits at 0.75 ms each. This is a query-pattern result. It is not a framework ranking.

Open-source applications

The Redmine workload sent authenticated reads to the Redmine 6.1.4 REST API. Its mix used 60% paginated issue lists, 30% issue details with journals, and 10% project lists. The test seeded 12 projects and 360 issues.

The Aimeos workload used a Laravel storefront and its demo catalog. It sent 60% product searches and 40% product detail requests. The catalog contained 17 products.

Redmine 6.1.4 ran with Rails 7.2.3.2. Aimeos used Laravel 13.33.0 and PHP 8.4. Both apps used PostgreSQL 18.6.

0 ms: Redmine 35.78 ms. Aimeos 65.74 ms.
0.05 ms: Redmine 45.11 ms, change +9.33 ms [8.10, 10.56]. Aimeos 64.47 ms, change -1.27 ms [-4.64, 1.85].
0.1 ms: Redmine 47.22 ms, change +11.43 ms [10.71, 12.63]. Aimeos 71.23 ms, change +5.48 ms [1.88, 7.17].
0.2 ms: Redmine 44.82 ms, change +9.03 ms [7.27, 10.60]. Aimeos 76.08 ms, change +10.33 ms [7.97, 11.80].
0.5 ms: Redmine 58.45 ms, change +22.67 ms [19.75, 23.84]. Aimeos 89.26 ms, change +23.51 ms [21.21, 25.29].
0.75 ms: Redmine 68.02 ms, change +32.23 ms [30.39, 34.80]. Aimeos 100.12 ms, change +34.37 ms [30.71, 35.80].
1 ms: Redmine 82.42 ms, change +46.63 ms [44.15, 51.09]. Aimeos 111.55 ms, change +45.80 ms [43.03, 48.55].

At 0.75 ms, the Redmine median increased by 90%. The Aimeos median increased by 52%. Each app showed about 32 to 34 ms of added request time from less than one millisecond of configured RTT. The ratio of the request increase to configured RTT was about 43 for Redmine and 46 for Aimeos. These ratios describe this workload and test setup. They are not database query counts.

The smallest Redmine settings did not follow a smooth progression. The 0.05 and 0.1 ms settings added more request time than a one-event-per-round-trip model predicts. At 0.05 ms, an uncached SELECT 1 call gained 0.077 ms at the median. Forty-one such waits would add about 3.2 ms, while the Redmine request median gained 9.3 ms. At 0.1 ms, the same model predicts 4.6 ms, while the request median gained 11.4 ms. The trace does not explain these differences.

Redmine SQL trace

A separate trace counted uncached Active Record SQL notification events for 100 requests. It did not run with the timing measurements. The trace saw 41 events per issue-list request at the median, 20 per issue-detail request, and 8 per project-list request.

Issue list: 60 requests, 41 events per request at the median, range 41 to 68.
Issue detail: 30 requests, 20 events at the median, range 20 to 30.
Project list: 10 requests, 8 events at the median, range 8 to 10.

The issue-list count is close to the measured amplification ratio. An SQL event count does not show whether each event caused a separate network round trip. A protocol trace would be needed to make that claim.

Measurement method

The app, database, and probe ran in separate Docker containers on the local DGX GB10 host. The test used one client. Linux tc netem added half of each target delay to the app container and half to the database container. The tested settings were 0, 0.05, 0.1, 0.2, 0.3, 0.4, 0.5, 0.75, and 1 ms. The task order was shuffled.

Each framework condition ran 20 times with 100 measured requests and 20 warmup requests per run. Redmine used the same run and request counts. Aimeos ran 10 times with 50 measured requests and 20 warmup requests per condition. No measured requests failed.

Each run produced a p50. The reported p50 is the median across run-level p50 values. The 95% CIs use 10,000 bootstrap samples of run-level p50 values. The CIs for changes resampled the baseline and target runs independently, then subtracted their medians.

A separate network check sent 50 ICMP packets between two local containers at each setting. The check used the same netem queue, including at 0 ms. It measured a mean RTT of 0.063 ms with no injected delay, 0.806 ms at a configured 0.75 ms, and 1.008 ms at a configured 1 ms. This checks the container network path. It does not measure a PostgreSQL query.

A second probe ran 200 uncached SELECT 1 calls through the Redmine Rails adapter in each of five runs per setting. At configured RTTs of 0.75 and 1 ms, median query times increased by 0.756 ms [0.736, 1.007] and 1.007 ms [0.988, 1.503]. This probe includes the Rails adapter and local host scheduling. Its medians varied at some lower settings.

Limits and next question

These were synthetic requests to real applications. They were not captured production traffic. The tests used one local host and one client. They do not measure cloud placement or predict latency for a managed database. The Redmine trace counted SQL notification events, not network exchanges. The smallest RTT settings need more investigation because the request deltas did not always match the standalone query probe.

The results motivate a follow-up systems question. Can a platform identify handlers that wait for many database results in sequence, then place only those handlers near the database primary? This experiment does not test such a scheduler.