Optimize per-request work dispatching to wasm #3063
Merged
+167
−131
Conversation
This file contains 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
This commit implements an optimization available from Wasmtime to improve the per-request dispatching to a wasm handler for an HTTP request. Previously the typed view of a request handler was loaded on each request but this involves somewhat expensive work such as: * A number of string lookups to find the right export. * A type-check to ensure that the component export has the right type. This can all be front-loaded to component-load time with `*Indices` structures that are generated by Wasmtime's `bindgen!` macro. This commit uses these generated structures to replace handler detection and then plumbs the final `*Indices` structure to dispatching the request so the dispatch doesn't need to perform extra work per-request. Signed-off-by: Alex Crichton <alex@alexcrichton.com>
alexcrichton
commented
Mar 26, 2025
Comment on lines
+44
to
+49
| .env("CARGO_TARGET_DIR", &out_dir) | ||
| // If RUSTFLAGS was set it'll be passed to this build script through | ||
| // this variable but since we're cross-compiling to wasm we almost | ||
| // surely don't want this to get picked up, so remove this from the | ||
| // destination flags. | ||
| .env_remove("CARGO_ENCODED_RUSTFLAGS"); |
There was a problem hiding this comment.
I'll note that this is technically unrelated to this change, but I've got [target.$my_host] rustflags = '...' on my local machine which was causing the build of tests to fail-by-default without this.
lann
reviewed
Mar 26, 2025
Comment on lines
+68
to
+71
| _ => anyhow::bail!( | ||
| "component exports multiple different handlers but \ | ||
| it's expected to export only one" | ||
| ), |
There was a problem hiding this comment.
I wonder if we really want to do this. Thinking to the future, if someone wants to build a component that works with wasi:http 0.2 or 0.3 and exports both, shouldn't we just pick 0.3?
There was a problem hiding this comment.
I think that'd be reasonable yeah, AFAIK this logic is a historical holdover at this point but having a tiered "if you export this we call it first" seems reasonable to me
rylev
approved these changes
Mar 27, 2025
|
(I'm also not able to merge this if someone wouldn't mind merging for me) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This commit implements an optimization available from Wasmtime to improve the per-request dispatching to a wasm handler for an HTTP request. Previously the typed view of a request handler was loaded on each request but this involves somewhat expensive work such as:
This can all be front-loaded to component-load time with
*Indicesstructures that are generated by Wasmtime'sbindgen!macro. This commit uses these generated structures to replace handler detection and then plumbs the final*Indicesstructure to dispatching the request so the dispatch doesn't need to perform extra work per-request.