Publish Server runtime comparison and image-tuning findings

[rmcdaniel]

Goal

Publish an engaging engineering post at /blog/ after Server #137's runtime comparison and Server #222's selected-image tuning have complete, verified results and final decisions. The operator supplied a public teaser and asked to wait for all results before publication. The current branch draft remains unpublished until both owning issues are complete.

Article

• Lead with a compact, comparable table of the six HTTP/PHP stacks and explain what the measurements mean for the production choice. Include the selected image's measured distribution, cold-start and runtime outcome after #222 is qualified. Put the exact tuple, workloads, limits and measurement scope near the table so readers can interpret it.
• Explain why standalone Server is a Laravel application, how its HTTP API, queue worker, scheduler, MySQL and Redis fit together, and why long polls and PHP worker occupancy matter to the stack choice.
• Briefly explain the wakeup, readiness, worker restart and client load findings that materially changed the numbers. Cover why another application could reasonably choose a different stack. Keep the post about results and engineering judgment rather than a PR timeline or exhaustive failure history.
• State material limits through clear table and method labels. Keep complete run histories, failures, commands, raw artifacts, source links and release evidence in Keep docs search current with the built site #137 and #222. Use one GitHub link at the end of the article to the consolidated public engineering record, with no inline PR or source links.
• Avoid semicolons, em dashes and self-critical caveat phrases. Use direct prose. Do not claim Cloud plan qualification or an advertised throughput guarantee from Server experiments.

Publication

After #137 and #222 are complete, replace the draft placeholders with the verified results. Review the complete draft in a site PR, run the site build and link checks, merge, and verify the live /blog/ post. Do not publish the draft before all results are in.

[rmcdaniel]

A source-backed article draft is on branch codex/server-runtime-blog-143. It is not published and has editorial placeholders for the benchmark table, final choice and selected-image tuning outcome. The operator has directed us to wait for all #137 and #222 results before publication and to lead with the measured comparison and what it means. The detailed run history stays in those Server issues; the article will link it and state any material limits that affect the conclusion.

Next: finish and verify both Server issues, replace the placeholders with the final evidence, run site build/link checks, then open the completed site PR for review and publication.

[rmcdaniel]

Editorial direction from the operator for the final post: lead with benchmark results and what they mean, then explain the Laravel Server architecture and the few findings that materially explain the numbers. Keep the full run history in the Server issues. Use one GitHub link at the end to the most relevant consolidated engineering record; no inline PR or source links. Avoid semicolons, em dashes, and self-critical caveat phrases such as “the local test does not establish a published capacity gain.” State measurement scope directly in the table/method labels. The branch draft now follows this shape, but still has placeholders and must remain unpublished until all #137 and #222 results are complete and verified.

[rmcdaniel]

Draft site PR #144 is open for the article. It is intentionally unmerged and will stay draft until Server #137 and #222 have complete verified results. The final table, recommendation, publication date, site build, and live verification remain the next actions.

[rmcdaniel]

Server #137 is closed with its six-model consolidated report and explicit disposition of unmeasured research. Server #222 is closed after release and exact-artifact verification of 2.4.27. Site PR #144 now contains the dated final article, with one GitHub link at the end. Its Node 24 production build and generated post check passed locally; the latest PR CI is in progress. Next: merge after the required checks pass, verify the live /blog/ post, and close this issue.

[rmcdaniel]

Published and verified: https://durable-workflow.com/blog/what-we-learned-testing-server-stacks/ returns HTTP 200 with the six-stack article, Server 2.4.27 image result and single consolidated engineering-report link. The /blog/ index also returns 200 and includes the post. PR #144 merged at 18017a391edc5721473720dec59e195a918d3d09 after all required checks passed; Pages deployment 36587932515 succeeded. The merged remote branch was deleted and verified absent. Server #137 and #222 were complete before publication. Closing this issue.