Anders Murphy

4 篇内容

工程实践Anders Murphy

Two apps one process

文章提出把多个 Web 应用放进同一个 JVM/进程运行,以共享堆、JIT、GC、HTTP 服务器、缓冲区、缓存和证书管理等固定开销,从而降低多应用部署的资源占用与线程竞争。作者把应用抽象为域名、SQLite 数据库迁移和路由,演示用 Clave 自动管理 HTTPS 证书、以依赖方式导入各应用并在 :apps 列表中注册,再打包 uberjar 后 scp 到服务器部署。文中也承认该方案依赖应用之间不需要进程级隔离,且所谓收益主要来自固定成本叠加,并未给出真实基准测试或故障隔离分析。适合评估单进程多应用架构的读者,但需注意共享进程会放大故障域、资源争用和升级耦合风险。

推荐收录,因为它给出了可运行的 Clojure 实现路径:共享 JVM/HTTP 服务器、Clave 证书管理、应用列表注册和 uberjar 部署均有代码片段,不是纯观点文。对探索低成本多应用托管、单进程多租户或资源复用的后端/架构读者有迁移价值;但文中缺乏基准数据和隔离性分析,采用前应补做故障域、内存上限和升级策略评估。

工程实践Anders Murphy

Lockstep to pipeline in almost one line

文章讨论把离散时间 tick 的 lockstep 系统改造为 pipeline 系统。Lockstep 中读、写阶段顺序执行,单 tick 耗时约为 write+read;pipeline 让读写阶段在不同线程并行,并用 CyclicBarrier 在 tick 边界同步,保留背压和超时统计。代码改动仅三行:把 done-barrier 移入循环,并在循环外先 await start-barrier。模拟慢写事务时,lockstep 的 p95 为 987ms、max 1195ms,而 pipeline 的 p95 为 100ms、max 105ms,几乎不受影响。读一致性由只读事务包裹每个渲染批次,并让读批次先于写批次启动来保证,必要时可加第三道 barrier。局限是它依赖固定阶段与 barrier 协调,篇幅短,未覆盖复杂故障与生产验证。

推荐收录。文章用三行代码 diff 和一个可复现的慢写模拟,直接展示了 lockstep 到 pipeline 的改造成本与收益:p95 从 987ms 降到 100ms,同时保留 tick 背压与读一致性。适合做后端、数据库或实时循环系统的工程师参考,其 barrier 同步、事务隔离和性能验证思路可迁移到类似 tick 架构;风险是方案依赖固定阶段模型,不适用于任意事件驱动系统。

工程实践Anders Murphy

Discrete time based systems are simple to benchmark

文章讨论离散时间/tick 驱动系统为何便于整体基准测试与负载测试,并以 Hyperlith 的流式 HTML 渲染为例。作者用 tick overrun 日志记录 p50/p95/p99/max,将性能问题转化为可观测的批次延迟,然后设计 12000 个长连接、其中 1/4 轻任务的本地负载场景,对比轮询预分配渲染线程与 ConcurrentLinkedQueue 共享任务队列。结果显示共享队列把 p50 从约 661ms 降到 361ms,约快 43%,并解释了批内 SQLite 读事务、避免外部压测脚本噪声等工程取舍。文章还指出该优势在负载不均时明显,但用户规模大、核数高或线程本地缓存生效时差距可能缩小,属于特定设计下的基准测试经验。

推荐收录:文章提供了完整的性能对比实验、代码片段与可复现的负载构造,显示 tick 系统如何用 overrun 日志和共享任务队列改善尾延迟。适合后端、数据库和性能工程读者借鉴其 benchmark 方法,尤其是批处理、并发队列和 SQLite 事务封装场景。风险是结论基于 4 核和极端负载分布,迁移到大规模系统需重新验证。

工程实践Anders Murphy

Faster streaming HTML with batches and aggregates

文章以 Clojure 实现为例,介绍一种服务端集中持有状态、通过 SSE 持续推送 HTML 帧(tick 驱动)的流式渲染架构及其优化路径。作者把固定 tick 当作批处理边界与读写屏障:先批量写入再批量渲染,并让每个渲染线程独占缓冲与数据库连接以消除竞争,使 1 万并发用户下的模板缓冲从 640MB 降到数百 KB,同时避免事件触发逐用户渲染造成的 O(N²) 放大。当 10 FPS、数千并发下 HTML 模板生成成为最后瓶颈时,他把组件建模为纯函数并按函数与参数做内容寻址缓存,借助 Caffeine 的 WTinyLFU 准入与淘汰机制抑制碎片化小条目引发的缓存抖动,并附优化前后火焰图对比。文中还说明 Brotli/Zstandard 流式压缩让整帧传输几乎不占带宽,SQLite 可作为按 tick 查询的投影存储。该方案依赖 tick 语义与服务端集中状态,对需要客户端本地状态或更低交互延迟的场景并不通用。

推荐收录:文章提供了可验证的工程证据——tick 批处理屏障与每线程独占资源把 1 万并发下的模板缓冲从 640MB 压到数百 KB,WTinyLFU 驱动的组件级内容寻址缓存,优化前后火焰图,以及 2 vCPU 上约 1000 并发、10 FPS 的生产数据。适合做实时协作、服务端渲染或高并发 Web 服务的工程师,其批处理边界、缓存准入策略与内存有界化思路可迁移;风险在于方案绑定 tick 语义、Clojure 运行时与嵌入式数据库,换栈需重新验证。