Conversation
|
Could you run one of the benchmark to check the impact of the atomic.Pointer on the hot path? |
|
The atomic pointer should be completely free on aarch64 and x86-64. If anything I should benchmark the check though. |
|
+3% (Go) instructions per request. Not terrible, but also not perfect... |
Requests that reach a PHP handler of a superseded runtime are handed to the matching module of the new app and dispatched on the new runtime. Hand-offs happen only before execution starts, so the body is unread, no response was written, and the request can be dispatched as is.
f965bcf to
b7cccf2
Compare
|
instead of old requests being rerouted through new route tree, we now take their existing state and execute it on the new runtime after the reload comes back. should be +/-0 instructions |
| return nil | ||
| case workerScaleChan <- fc: | ||
| // the request has triggered scaling, continue to wait for a thread | ||
| case <-worker.done: |
There was a problem hiding this comment.
For a 0-runtime overhead solution you could also just have a goroutine drain all worker.requestChans after reload for some amount of time.
| maxThreads int | ||
| requestOptions []RequestOption | ||
| requestChan chan *frankenPHPContext | ||
| done <-chan struct{} |
There was a problem hiding this comment.
It probably would make sense to store and check readiness somewhere on the Server directly and not re-use them across reloads.
Would be a bit of a bigger refactor,.but IMO the behavior should be the same for regular threads and workers.
This branch has not been deployed
3 participants
edit: just a reminder to myself to do it properly after api con
edit: prevent 503s from requests coming in during config reloads (complementary to nicolas' PR #2661)