-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASM middleware state not kept #10953
Comments
Hello @darkweak , For the wasm plugin middlewares, it works with a pool so it's possible that when the second request happens, the first middleware was not yet back in the pool. You can see in your logs that the third request does not call the "INIT". |
Hey @juliens, do you have clues to prevent that? |
Do you have a reason to prevent this? It's designed to handle multiple requests in parallel. The pool should be populated over time, and once it's filled, it shouldn't call INIT anymore. |
I'm migrating the HTTP cache from go middleware to the WASM middleware (due to limitations from yægi). |
The pool may remove some instances from the pool, I believe to refresh old instances, but it doesn't instantiate for each requests. With your example middleware: |
That means, it could create so much connections to the storage provider (e.g. redis/etcd) and there is no way to avoid reinitialization. |
Yes, the current implementation of the WASM plugin middleware in Traefik does have some limitations, particularly regarding the instance pool and initialization behavior you're observing. Each middleware instance may get reinitialized more frequently than desired, especially with external connections like Redis or etcd and with shared-memory cache. However, as there is a pool, the situation is not as dramatic as it might sound. The pool is designed to manage multiple requests in parallel and, over time, it should stabilize, reducing the frequency of initialization calls. This helps mitigate the performance impact to some extent. Moreover, there are ways to improve this situation that we could try in the futur: Shared In-Memory Objects: One potential improvement is to add support for shared objects in memory. This would allow instances to share certain data, reducing the need to reinitialize connections or cache data on each request. Enhanced Pool Management: Enhancing the pool's management strategies to improve instance lifetime can help mitigate excessive reinitialization. This includes better handling of pool resizing and more stable instance retention policies. Clean callback: In the Yaegi middleware, when a middleware is not used anymore, the context used in the instanciation is Done, it's not the case in wasm plugin, so it could be a good idea to have a callback to free resource like ecxternal connection to avoid infinite connection. |
Thank you for taking in consideration this feedback. I hope the |
Welcome!
What did you do?
I'm actually looking at the WASM support for plugins in Træfik as @emilevauge mentioned but with this minimal snippet, we can see that the init is called when I send an HTTP request to Træfik
I would like to know if that's the normal behavior or if that's a bug.
IMHO loading WASM plugins as stateless and reconfigure them each time you go through the middleware is a performance issue.
What did you see instead?
What version of Traefik are you using?
Traefik version 3.1.0 built on 2024-07-15T14:44:04Z
What is your environment & configuration?
If applicable, please paste the log output in DEBUG level
The text was updated successfully, but these errors were encountered: