Repository navigation
viltrum: update to 1.1.0 (zero-allocation core, async) - #1566
Conversation
|
/benchmark -f viltrum --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
|
|
Benchmark ResultsFramework: No results captured Full log |
|
/benchmark -f viltrum --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
This framework falls into experimental "type", please adjust |
|
Done: |
|
Quick follow-up question: what would it take for viltrum to move from |
Mostly on production experience, time does help but not the main factor. Typically, I look for at least some users or ecosystem around it, sometimes through contributions, issues, people referencing it online on social medias etc. There are also some cases that don't have much on these but the framework is built on top of existing work like uwebsockets, bun etc. I looked into your project and still feels very young, also using your own engine doesn't help the case as one more layer that needs production hardening. Nevertheless, I hope you keep working on it and one day we can move to emerging. |
|
I've also added the async profile here (viltrum 1.1.0, |
|
/benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
|
|
Benchmark ResultsFramework: No results captured Full log |
…e /baseline11 endpoint)
|
/benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
Updates the viltrum entry to 1.1.0: the 1.0 zero-allocation core plus deferred responses for the async profile.
The last run showed viltrum using only 11–23 of the 64 cores. 1.0 removes per-request GC allocation from the framework (enforced by a test in CI) and drops spawn-per-connection in favour of one
SO_REUSEPORTepoll worker per CPU.c.json) and framework gzip per request. No responses are cached or precomputed.GET /baseline11endpoint; the workers block inepoll_waitwith no busy-poll or fixed-cadence timer, and size to the cpuset), and now async. echo-ws is removed because WebSocket is not in viltrum 1.0 yet; it returns on the new core later.GET /delay/:msusesc.after(ms, cb, arg): the handler returns at once and the engine writes the response from a per-worker timer heap, so a worker is never held while a request waits.VILTRUM_REF=v1.1.0.validate.sh viltrumpasses (37 passed, 0 failed), including the async checks (random delay, parameter-driven delay, 32 overlapping requests with different delays).