zix http1 entry - #998
Open
prothegee wants to merge 79 commits into
Open
Conversation
Contributor
Author
|
Testing new approach and database tests entries for H1. |
Contributor
Author
|
/benchmark -f zix |
Contributor
|
👋 |
Contributor
Benchmark ResultsFramework:
Full log |
Contributor
Author
|
Oh my, didn't expect the cpu burn that much with high memory consumption. |
prothegee
marked this pull request as draft
July 15, 2026 20:09
prothegee
marked this pull request as ready for review
July 21, 2026 02:43
… propagation - Migrate JSON parsing and serialization across `json`, `crud`, and `dataset` modules to use `jzon`, eliminating manual string building and `std.json` overhead. - Remove response memoization and startup pre-serialization. The `json` handler now serializes per request, and `crudcache` strictly operates as a row-level cache-aside (holding decoded DB rows, not rendered HTTP responses) to accurately reflect benchmark profile constraints. - Replace the custom `static` handler with the engine's native `public_dir` configuration. - Enforce strict error propagation by converting handlers and shared responders (`response.zig`) to return `!void`, replacing silent error swallowing with `try`. - Centralize byte-buffer formatting utilities (integers, strings, JSON escaping) into `shared/util.zig`. - Refactor `dbpg` to use a shared `CrudWrite` payload for create/update jobs and improve lane arming logic for `.URING` vs `.EPOLL`/`.ASYNC` models. - Add comprehensive module-level documentation explaining design choices, benchmark constraints, and engine interactions. - Update `Dockerfile` to target Zix `0.5.x` and change Zig build summary to `failures`. - Add `static-tls` to the `meta.json` test matrix.
Contributor
Author
|
Bump zix branch to 0.5.x and follow-up #1121 (comment) |
Contributor
Author
|
/benchmark -f zix |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Contributor
Benchmark ResultsFramework:
Full log |
Contributor
Author
|
/benchmark -f zix --save |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Contributor
Benchmark ResultsFramework:
Full log |
Contributor
Author
|
Hi, open to review for this pull-request. |
Contributor
Author
|
#997 and #982 already merged, but this p.r. skipped. 83aa9f0 already done. Looking forward. |
Owner
Did you look into these points? |
Contributor
Author
Yes, crud ttl already addressed. For the upload you can verify it in the handler implementation. It physically reads and processes the data into memory. First it read into engine memory, Then the handler explicitly copies those bytes into local buffer. const taken = @min(body.len, SINK_BYTES);
@memcpy(tl_sink[0..taken], body[0..taken]);Finally, the output is checked from const received: u64 = req.bodyReceived();
var body_buf: [COUNT_BUF]u8 = undefined;
const out = try std.fmt.bufPrint(&body_buf, "{d}", .{received});
try zix.Http1.sendSimpleFD(fd, @intFromEnum(zix.Http1.Status.Code.OK), zix.Http1.Content.Type.TEXT_PLAIN.asString(), out);Reference test of the size to be expected equal. Now for the json handler. It physically serializes the json payload per request, not caching the serialized string at startup (no initialize data cache in main). First it loads the dataset into engine memory as raw typed values (integers, strings, structs), not as pre-rendered json bytes. // dataset.zig
const items = try jzon.deserialize([]const Item, allocator, raw, .{
.strategy = .GENERATED,
.strings = .BORROW,
});Then the handler dynamically reads the request query parameter // json.zig
const multiplier: u64 = if (zix.Http1.queryParam(head, "m")) |raw|
std.fmt.parseInt(u64, raw, 10) catch 1
else
1;Finally, the handler serializes the json body on every single request into a local buffer (or directly into the engine's send buffer), and sends it. // json.zig
const body_len = renderBody(body, rows, count, multiplier) catch {
try response.badRequest(fd);
return;
};
// ... then sends it dynamicallyWhen the processing data fails, it will call |
Owner
|
Ok, great! I will take a look at it again, this entry takes some time to review because of the size of it. |
Contributor
Author
|
Sure. I'll keep updating from the main branch too. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
zix entry for http1 using 0.5.x branch.
Update:
Checklist:
/benchmark -f zix/benchmark -f zix --save