It has been observed that after a period of no traffic, the first database-backed request (for example, randomizing a patient) takes about 3 seconds, while the second identical request takes about 0.8 seconds. This pattern repeats after quiet spells.
Hypotheses:
The API creates a global PostgreSQL pool during startup without configuring any keep-alive, idleTimeout, or minSize settings. As a result, the runtime depends on the defaults of pool::dbPool and the database server. After a quiet spell, the next request must re-open a connection, which matches the observed multi-second delay.
Randomization requests immediately hit the pool through dplyr::tbl() and DBI::dbGetQuery(), so the first call after idle pays the reconnection cost while subsequent calls reuse the warm session and complete quickly.
Audit logging relies on pool::localCheckout() as well, so the same idle or keep-alive behavior can affect other endpoints unless the pool remains warm.
There should be a facility to change this behavior for time-sensitive users.
It has been observed that after a period of no traffic, the first database-backed request (for example, randomizing a patient) takes about 3 seconds, while the second identical request takes about 0.8 seconds. This pattern repeats after quiet spells.
Hypotheses:
The API creates a global PostgreSQL pool during startup without configuring any
keep-alive,idleTimeout, orminSizesettings. As a result, the runtime depends on the defaults ofpool::dbPooland the database server. After a quiet spell, the next request must re-open a connection, which matches the observed multi-second delay.Randomization requests immediately hit the pool through
dplyr::tbl()andDBI::dbGetQuery(), so the first call after idle pays the reconnection cost while subsequent calls reuse the warm session and complete quickly.Audit logging relies on
pool::localCheckout()as well, so the same idle or keep-alive behavior can affect other endpoints unless the pool remains warm.There should be a facility to change this behavior for time-sensitive users.