zix http1 entry - #998
Conversation
|
Testing new approach and database tests entries for H1. |
|
/benchmark -f zix |
|
👋 |
Benchmark ResultsFramework:
Full log |
|
Oh my, didn't expect the cpu burn that much with high memory consumption. |
|
Fixed has been made. |
|
/benchmark -f zix |
|
👋 |
|
Below the adjustment/reworked as follows: json / json-comp / json-tls: Requested: serialize (and compress) per request, remove the response cache from the Change (
upload: Requested: count the bytes actually read off the socket and return that count. Change (
crud: Requested: single-item read TTL 200 ms, drop the list-response cache. Change (
|
Benchmark ResultsFramework:
Full log |
|
/benchmark -f zix --save |
|
👋 |
Requesting review before |
Benchmark ResultsFramework:
Full log |
This branch saved results before MDA2AV#1034, so it carries 20 site/data/<profile>-<conns>.json files that main has since replaced with one file per framework; git reported them all as modify/delete conflicts. Every row this PR added or changed against its merge base was re-applied to site/data/results/zix.json and the flat files dropped - 8 profiles this entry did not publish before (api-4, api-16, async-db, crud, json-comp at three connection counts, json-tls) and 12 it updated (baseline, limited-conn, pipelined, json, static, upload). Two keys already in main were left alone, because this PR did not touch them.
|
/benchmark -f zix --save |
|
👋 |
Benchmark ResultsFramework:
Full log |
|
Ready to review before merge, @MDA2AV |
Beem kinda busy, I'll do a full review tommorow, need some time to do it properly |
Sure. Hope you doin well. Regards. |
|
Ok, I reviewed again. Some things improved but some issues remain. On the upload test, I must say your AI agent really went all in on this test.. technically following the rules but doing something no server would ever do. You count the bytes received but discard them and never read into zix's memory.. it is expected that a server reads the request data to its memory. As this is an engine and test is not scored, we can allow this but keep in mind this would never work on a production server. On json tests, you need to serialize per request, not caching the serialized data at startup and then serve it. This one is important as json-tls is a scored test. There are a lot other things zix is doing that are clearly benchmark oriented and would be a very big problem in a production use, however this is engine section so I won't pick on that but if you are planning on using it as an engine for a real server, there are quite a lot of issues. On CRUD, the ttl seems to be addressed. Regardless, it is an interesting project to push benchmark numbers! :) |
|
Yes, zix.Http1 intent really rely on user implementation and promote for user control. I knew it's engine category, but engine correctness is considerable aspect (despite some zix engine/s features). Converting to draft. Thank you. |
Description
zix entry for http1 using 0.5.x-rc2 branch.
Update:
Checklist:
/benchmark -f zix/benchmark -f zix --save