You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/fr/performance.md
+56-15Lines changed: 56 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,26 +5,26 @@ Cependant, il est possible d'améliorer considérablement les performances en ut
5
5
6
6
## Nombre de threads et de workers
7
7
8
-
Par défaut, FrankenPHP démarre deux fois plus de threads et de workers (en mode worker) que le nombre de CPU disponibles.
8
+
Par défaut, FrankenPHP démarre deux fois plus de threads et de workers (en mode worker) que le nombre de cœurs de CPU disponibles.
9
9
10
10
Les valeurs appropriées dépendent fortement de la manière dont votre application est écrite, de ce qu'elle fait et de votre matériel.
11
-
Nous recommandons vivement de modifier ces valeurs.
11
+
Nous recommandons vivement de modifier ces valeurs. Pour une stabilité optimale du système, il est recommandé d'avoir `num_threads` x `memory_limit` < `available_memory`.
12
12
13
-
Pour trouver les bonnes valeurs, il est souhaitable d'effectuer des tests de charge simulant le trafic réel.
13
+
Pour trouver les bonnes valeurs, il est préférable d'effectuer des tests de charge simulant le trafic réel.
14
14
[k6](https://k6.io) et [Gatling](https://gatling.io) sont de bons outils pour cela.
15
15
16
16
Pour configurer le nombre de threads, utilisez l'option `num_threads` des directives `php_server` et `php`.
17
-
Pour changer le nombre de travailleurs, utilisez l'option `num` de la section `worker` de la directive `frankenphp`.
17
+
Pour changer le nombre de workers, utilisez l'option `num` de la section `worker` de la directive `frankenphp`.
18
18
19
19
### `max_threads`
20
20
21
21
Bien qu'il soit toujours préférable de savoir exactement à quoi ressemblera votre trafic, les applications réelles
22
-
ont tendance à être plus imprévisibles. Le paramètre`max_threads` permet à FrankenPHP de créer automatiquement des threads supplémentaires au moment de l'exécution, jusqu'à la limite spécifiée.
22
+
ont tendance à être plus imprévisibles. La [configuration](config.md#configuration-du-caddyfile)`max_threads` permet à FrankenPHP de créer automatiquement des threads supplémentaires au moment de l'exécution, jusqu'à la limite spécifiée.
23
23
`max_threads` peut vous aider à déterminer le nombre de threads dont vous avez besoin pour gérer votre trafic et peut rendre le serveur plus résistant aux pics de latence.
24
24
Si elle est fixée à `auto`, la limite sera estimée en fonction de la valeur de `memory_limit` dans votre `php.ini`. Si ce n'est pas possible,
25
25
`auto` prendra par défaut 2x `num_threads`. Gardez à l'esprit que `auto` peut fortement sous-estimer le nombre de threads nécessaires.
26
26
`max_threads` est similaire à [pm.max_children](https://www.php.net/manual/en/install.fpm.configuration.php#pm.max-children) de PHP FPM. La principale différence est que FrankenPHP utilise des threads au lieu de
27
-
processus et les délègue automatiquement à différents scripts de travail et au `mode classique` selon les besoins.
27
+
processus et les délègue automatiquement à différents scripts worker et au 'mode classique' selon les besoins.
28
28
29
29
## Mode worker
30
30
@@ -34,18 +34,18 @@ vous devez créer un script worker et vous assurer que l'application n'a pas de
34
34
35
35
## Ne pas utiliser musl
36
36
37
-
Les binaires statiques que nous fournissons, ainsi que la variante Alpine Linux des images Docker officielles, utilisent [la bibliothèque musl](https://musl.libc.org).
37
+
La variante Alpine Linux des images Docker officielles et les binaires par défaut que nous fournissons utilisent [la bibliothèque musl](https://musl.libc.org).
38
38
39
-
PHP est connu pour être [significativement plus lent](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14381) lorsqu'il utilise cette bibliothèque C alternative au lieu de la bibliothèque GNU traditionnelle,
40
-
surtout lorsqu'il est compilé en mode ZTS (_thread-safe_), ce qui est nécessaire pour FrankenPHP.
39
+
PHP est connu pour être [plus lent](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14381) lorsqu'il utilise cette bibliothèque C alternative au lieu de la bibliothèque GNU traditionnelle,
40
+
surtout lorsqu'il est compilé en mode ZTS (_thread-safe_), ce qui est nécessaire pour FrankenPHP. La différence peut être significative dans un environnement fortement multithreadé.
41
41
42
42
En outre, [certains bogues ne se produisent que lors de l'utilisation de musl](https://github.com/php/php-src/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+label%3ABug+musl).
43
43
44
-
Dans les environnements de production, nous recommandons fortement d'utiliser la glibc.
44
+
Dans les environnements de production, nous recommandons d'utiliser FrankenPHP lié à glibc, compilé avec un niveau d'optimisation approprié.
45
45
46
-
Cela peut être réalisé en utilisant les images Docker Debian (par défaut) et [en compilant FrankenPHP à partir des sources](compile.md).
46
+
Cela peut être réalisé en utilisant les images Docker Debian, en utilisant [les paquets .deb, .rpm ou .apk proposés par l'un de nos mainteneurs](https://pkgs.henderkes.com), ou en [compilant FrankenPHP à partir des sources](compile.md).
47
47
48
-
Alternativement, nous fournissons des binaires statiques compilés avec [l'allocateur mimalloc](https://github.com/microsoft/mimalloc), ce qui rend FrankenPHP+musl plus rapide (mais toujours plus lent que FrankenPHP+glibc).
48
+
Pour des conteneurs plus légers ou plus sécurisés, vous pourriez envisager [une image Debian renforcée](docker.md#hardening-images) plutôt qu'Alpine.
49
49
50
50
## Configuration du runtime Go
51
51
@@ -84,11 +84,23 @@ vous pouvez les désactiver en définissant explicitement `try_files` comme ceci
84
84
```caddyfile
85
85
php_server {
86
86
try_files {path} index.php
87
-
root /root/to/your/app # l'ajout explicite de la racine ici permet une meilleure mise en cache
87
+
root /root/to/your/app # l'ajout explicite de la racine ici permet une meilleure mise en cache
88
88
}
89
89
```
90
90
91
91
Cela permet de réduire considérablement le nombre d'opérations inutiles sur les fichiers.
92
+
Un équivalent worker de la configuration précédente serait :
93
+
94
+
```caddyfile
95
+
route {
96
+
php_server { # utilisez "php" au lieu de "php_server" si vous n'avez pas du tout besoin du serveur de fichiers
97
+
root /root/to/your/app
98
+
worker /path/to/worker.php {
99
+
match * # envoie toutes les requêtes directement au worker
100
+
}
101
+
}
102
+
}
103
+
```
92
104
93
105
Une approche alternative avec 0 opérations inutiles sur le système de fichiers serait d'utiliser la directive `php`
94
106
et de diviser les fichiers de PHP par chemin. Cette approche fonctionne bien si votre application entière est servie par un seul fichier d'entrée.
@@ -105,10 +117,10 @@ route {
105
117
root /root/to/your/app
106
118
}
107
119
108
-
# tout ce qui n'est pas dans /assets est géré par votre index ou votre fichier PHP worker
120
+
# tout ce qui n'est pas dans /assets est géré par votre fichier PHP d'index ou worker
109
121
rewrite index.php
110
122
php {
111
-
root /root/to/your/app # l'ajout explicite de la racine ici permet une meilleure mise en cache
123
+
root /root/to/your/app # l'ajout explicite de la racine ici permet une meilleure mise en cache
112
124
}
113
125
}
114
126
```
@@ -155,3 +167,32 @@ En particulier :
155
167
156
168
Pour plus de détails, lisez [l'entrée de la documentation dédiée de Symfony](https://symfony.com/doc/current/performance.html)
157
169
(la plupart des conseils sont utiles même si vous n'utilisez pas Symfony).
170
+
171
+
## Division du pool de threads
172
+
173
+
Il est courant que les applications interagissent avec des services externes lents, comme une
174
+
API qui a tendance à être peu fiable sous forte charge ou qui met constamment plus de 10 secondes à répondre.
175
+
Dans de tels cas, il peut être bénéfique de diviser le pool de threads pour avoir des pools "lents" dédiés.
176
+
Cela empêche les points d'accès lents de consommer toutes les ressources/threads du serveur et
177
+
limite la concurrence des requêtes se dirigeant vers le point d'accès lent, à l'instar d'un
178
+
pool de connexions.
179
+
180
+
```caddyfile
181
+
example.com {
182
+
php_server {
183
+
root /app/public # la racine de votre application
184
+
worker index.php {
185
+
match /slow-endpoint/* # toutes les requêtes avec le chemin /slow-endpoint/* sont gérées par ce pool de threads
186
+
num 1 # minimum 1 thread pour les requêtes correspondant à /slow-endpoint/*
187
+
max_threads 20 # autorise jusqu'à 20 threads pour les requêtes correspondant à /slow-endpoint/*, si nécessaire
188
+
}
189
+
worker index.php {
190
+
match * # toutes les autres requêtes sont gérées séparément
191
+
num 1 # minimum 1 thread pour les autres requêtes, même si les points d'accès lents commencent à bloquer
192
+
max_threads 20 # autorise jusqu'à 20 threads pour les autres requêtes, si nécessaire
193
+
}
194
+
}
195
+
}
196
+
```
197
+
198
+
De manière générale, il est également conseillé de gérer les points d'accès très lents de manière asynchrone, en utilisant des mécanismes pertinents tels que les files d'attente de messages.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&size=40){kind=avatar}
0 commit comments