-
Notifications
You must be signed in to change notification settings - Fork 420
docs: Add warning on stateful services and shared memory model #1951
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
base: main
Are you sure you want to change the base?
docs: Add warning on stateful services and shared memory model #1951
Conversation
34f1eea to
3f7bd27
Compare
|
Thank you for the contribution, please add the English page as well, as that's the authoritative version. I'm also not quite happy with the statement that workers introduce a shared-memory model. They don't really do that, they just don't reset the state between requests. They still don't share memory with other parallel requests. |
3f7bd27 to
32abca1
Compare
32abca1 to
a7adc67
Compare
777a85e to
f9a297a
Compare
906b05a to
bc43d35
Compare
bc43d35 to
911ca08
Compare
docs/fr/worker.md
Outdated
|
|
||
| ## Avertissement sur la conception Stateful | ||
|
|
||
| Contrairement au modèle PHP-FPM traditionnel, l'application reste chargée en mémoire entre les requêtes. Par conséquent, tout état stocké dans vos services (propriétés d'objet, singletons, etc.) sera conservé et partagé entre les requêtes successives traitées par le même worker. Cela peut entraîner des fuites de données ou des états incohérents si votre application n'est pas conçue pour cela. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Des fuites de données ou de mémoire
docs/fr/worker.md
Outdated
| ## Avertissement sur la conception Stateful | ||
|
|
||
| Contrairement au modèle PHP-FPM traditionnel, l'application reste chargée en mémoire entre les requêtes. Par conséquent, tout état stocké dans vos services (propriétés d'objet, singletons, etc.) sera conservé et partagé entre les requêtes successives traitées par le même worker. Cela peut entraîner des fuites de données ou des états incohérents si votre application n'est pas conçue pour cela. | ||
| L'article suivant résume ce problème et explique comment y remédier, notamment pour les applications Symfony en utilisant ResetInterface pour garantir que vos services sont "propres" à chaque nouvelle requête. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Que vos services sont « réinitialisés »
a6fb2a7 to
75bc5ac
Compare
75bc5ac to
8533696
Compare
|
I'm not a fond of the external link. They make the info harder to find. Couldn't we replace them with some examples? We should also hint about the Symfony |
|
Hello 😄 I understand the comment. I have my doubts too, but I thought it would be better to cite my source than just copy and paste. I'll take a look at that. I have already tried setting the maximum number of requests to 1, but then the benefit of worker mode is minimal or even non-existent in terms of performance, or am I wrong? Another question: is there a risk with libraries installed in a project? Even if I implement security measures in my code to ensure that I am managing statelessness correctly, how can I be sure that the problem cannot come from elsewhere? |
|
Hello 😄 , do you have any other feedback? @dunglas @alexandre-daubois @94noni |
This Pull Request proposes an update to the documentation to better explain FrankenPHP's Worker Mode.
The goal is to provide clear information regarding:
Associated Risks of state persistence (stateful services) across consecutive requests.
Best practices and tools (such as Symfony's ResetInterface or phanalist) to ensure a successful migration of applications to this high-performance model.
This clarification aims to prevent unexpected behaviors and facilitate the adoption of Worker Mode.