Add Dream: OCaml web framework (first OCaml entry!)#25
Add Dream: OCaml web framework (first OCaml entry!)#25BennyFranciscus wants to merge 8 commits intoMDA2AV:mainfrom
Conversation
The dune file was missing the lwt_ppx preprocessor, so `let%lwt` was treated as an uninterpreted extension. Added `(preprocess (pps lwt_ppx))` to the executable stanza.
|
Build fix: the dune file was missing the Added |
OCaml 5.2's Float.round takes float -> float (no precision arg). The second definition using round2 was correct but shadowed by the broken first one. Removed the dead code.
|
Build fix: there was a duplicate Removed the dead duplicate. Should compile clean now 🤞 |
Dream doesn't have built-in compression middleware, so we need to handle it ourselves. Added camlzip dependency and pre-compress the large JSON response at startup. Serves gzipped response when client sends Accept-Encoding: gzip. Also fixed unused variable warning (tags -> _tags in db query).
|
CI fix: compression endpoint was missing gzip support! Dream doesn't include built-in compression middleware, so the Fix:
Also fixed the Waiting on CI to re-run — will need workflow approval since this is a first-time contributor fork. |
Benchmark ResultsFramework: Full log |
|
@BennyFranciscus single threaded |
|
Yep, Dream is single-threaded — OCaml's Lwt is a cooperative concurrency model on one core. The 32K baseline is actually solid for single-threaded OCaml. Dream does support running behind a reverse proxy for multi-core, but there's no built-in multi-process mode. I could try a fork-based approach (spawn N processes on SO_REUSEPORT), but OCaml's Happy to try it if you think it's worth adding multi-core support, or we can leave it as a showcase of single-threaded perf. Let me know! |
is single threaded the intended way to use it? Don't think so, check its docs |
Dream is single-threaded (OCaml's Lwt cooperative concurrency), so multi-core requires multiple processes. Approach: - Unix.fork() spawns one worker per CPU core - Each child runs its own Dream server on port 8080 - SO_REUSEPORT is set via LD_PRELOAD shim (libreuseport.so) since Dream/Lwt_io doesn't expose SO_REUSEPORT on the listening socket - Kernel distributes incoming connections across workers The LD_PRELOAD shim intercepts bind() to set SO_REUSEPORT before the real bind, allowing multiple processes to share the same port. Falls back to single-process when only 1 CPU is available.
|
Good call — checked Dream's docs and source. Dream doesn't have built-in multi-process/multi-core, but it's definitely not intended to run single-threaded in production. The OCaml approach is to run multiple processes sharing the same port. Implementation:
The LD_PRELOAD approach is clean — it's a 14-line C file that intercepts Pushed — waiting on CI to run! Curious to see how the single-threaded 32K baseline scales across cores 🔬 |
|
canceled validation - stuck on waiting server. |
|
On it — likely an issue with Dream/Lwt initialization and the fork. OCaml's Lwt can have subtle issues with Let me check the CI logs and push a fix. Might need to restructure the startup order or add a readiness signal. |
OCaml's Unix.fork() + Lwt causes server startup to hang — Lwt's event loop state doesn't survive fork cleanly. Replaced with a shell script that spawns N independent server processes, each with its own clean Lwt event loop. SO_REUSEPORT via LD_PRELOAD still distributes connections across workers.
|
Fix for the startup hang: OCaml's New approach: Moved multi-process to a shell wrapper ( Simpler and more reliable than trying to manage fork semantics in OCaml. Waiting on CI! 🤞 |
Dream runs a single-threaded Lwt event loop per process. Fork N workers (one per CPU) with SO_REUSEPORT for multi-core scaling. Replaces shell wrapper approach for more reliable process management.
|
good call — pushed a fix. Dream runs a single-threaded Lwt event loop, so the right approach is forking N workers (one per CPU core). switched to in-process Unix.fork with the SO_REUSEPORT shim so each worker binds the same port. OCaml's Unix.fork is a direct syscall wrapper so it's way more reliable than the shell wrapper approach that was getting stuck. should properly use all cores now! |
Dream/Lwt's libev event loop state doesn't survive Unix.fork() — children accept TCP connections but never process them (event loop corrupted). Fixed by making server.ml purely single-process and delegating multi-core to run.sh (N independent /server processes with SO_REUSEPORT via LD_PRELOAD). Also removed deprecated ~adjust_terminal parameter.
|
Found the root cause of the startup hang! 🐛 OCaml's Lwt uses libev under the hood, and libev's event loop state doesn't survive Fix: Removed all fork logic from Also cleaned up the deprecated Tested locally — server starts instantly and responds correctly. Should be good for CI now! |
|
CI failed due to a stale container from the previous cancelled run — Could you re-run the validation? The fix itself is clean — removed all in-process forking, now using the shell wrapper approach (same as Kemal). Each worker gets a fresh Lwt/libev event loop. 🙏 |
|
Apologies for mentioning this here, but our cooperative has decided to develop its own framework in OCaml (which takes advantage of multi-core processing): vif (for which a tutorial is available here. We have also produced a benchmark proposal here (the results of which are available here. We also decided to propose a benchmark protocol which gave us these results. In other words, I would be delighted to contribute to a proposal that uses vif and/or httpcats, but Dream is no longer a solution we are considering for OCaml and unikernels. |
|
Oh this is really cool @dinosaure! 🎉 vif looks super interesting — native multicore OCaml with Dream is still worth having here as the most well-known OCaml web framework (~1.6k stars, lots of production users), but I'd love to see vif as a separate entry — it'd be a great way to show what OCaml 5's multicore can really do. Would you be up for opening a PR to add vif? The setup is pretty straightforward: a Dockerfile, the app implementing a few endpoints (plaintext, json, db queries via SQLite, file upload, compression), and a meta.json. Happy to help if you want a starting point — I can put together a skeleton based on the Dream entry. The httpcats benchmark protocol is interesting too. Different approach from what HttpArena does (wrk2/bombardier based) but the methodology around latency measurement looks solid. |
Ah I see, will drop this framework and would be great to have a vif or httpcats :) We can draft a quick PR and run a benchmark over it with quick results if you prefer. |
3 participants
Dream — OCaml Web Framework
Adds Dream as the first OCaml entry in HttpArena! 🐫
Why Dream?
Dream is a tidy, feature-complete web framework for OCaml with ~1,800 stars. It's built on httpaf/h2 with Lwt async I/O, and compiles to efficient native machine code via the OCaml 5 compiler.
What makes it interesting for benchmarks:
Implementation
/pipeline,/baseline11,/baseline2,/json,/compression,/db,/upload,/static/{filename}Yojsonfor JSON serializationsqlite3-ocamlbindings for the/dbendpoint--releaseoptimizationsNew language!
This is the first OCaml framework in HttpArena. OCaml is a really cool language that sits at the intersection of functional programming and systems performance — it'd be awesome to see how it stacks up against the other compiled language entries.
cc @aantron @dinosaure @yawaramin — thought it'd be cool to see how Dream stacks up in HttpArena! Dream's API is genuinely one of the cleanest web framework interfaces I've seen in any language.