docs: update translations

docs/cn/performance.md

@@ -5,7 +5,7 @@
 
 ## 线程和 Worker 数量
 
-默认情况下，FrankenPHP 启动的线程和 worker（在 worker 模式下）数量是可用 CPU 数量的 2 倍。
+默认情况下，FrankenPHP 启动的线程和 worker（在 worker 模式下）数量是可用 CPU 核心数的 2 倍。
 
 适当的值很大程度上取决于你的应用程序是如何编写的、它做什么以及你的硬件。
 我们强烈建议更改这些值。为了获得最佳的系统稳定性，建议 `num_threads` x `memory_limit` < `available_memory`。
@@ -41,11 +41,11 @@
 
 另外，[一些错误只在使用 musl 时发生](https://github.com/php/php-src/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+label%3ABug+musl)。
 
-在生产环境中，我们建议使用链接到 glibc 的 FrankenPHP。
+在生产环境中，我们建议使用链接到 glibc 的 FrankenPHP，并使用适当的优化级别进行编译。
 
-这可以通过使用 Debian Docker 镜像（默认）、从我们的 [Releases](https://github.com/php/frankenphp/releases) 下载 -gnu 后缀二进制文件，或通过[从源代码编译 FrankenPHP](compile.md) 来实现。
+这可以通过使用 Debian Docker 镜像、使用[我们的维护者提供的 .deb、.rpm 或 .apk 包](https://pkgs.henderkes.com)，或通过[从源代码编译 FrankenPHP](compile.md) 来实现。
 
-或者，我们提供使用 [mimalloc 分配器](https://github.com/microsoft/mimalloc) 编译的静态 musl 二进制文件，这缓解了线程场景中的问题。
+对于更精简或更安全的容器，你可能需要考虑使用[强化的 Debian 镜像](docker.md#hardening-images)而不是 Alpine。
 
 ## Go 运行时配置
 
@@ -89,6 +89,18 @@ php_server {
 ```
 
 这可以显著减少不必要的文件操作数量。
+上述配置的 worker 等效项为：
+
+```caddyfile
+route {
+    php_server { # 如果完全不需要文件服务器，请使用 "php" 而不是 "php_server"
+        root /root/to/your/app
+        worker /path/to/worker.php {
+            match * # 将所有请求直接发送到 worker
+        }
+    }
+}
+```
 
 另一种具有 0 个不必要文件系统操作的方法是改用 `php` 指令并按路径将
 文件与 PHP 分开。如果你的整个应用程序由一个入口文件提供服务，这种方法效果很好。
@@ -148,10 +160,35 @@ FrankenPHP 使用官方 PHP 解释器。
 
 特别是：
 
-- 检查 [OPcache](https://www.php.net/manual/zh/book.opcache.php) 是否已安装、启用并正确配置
+- 检查 [OPcache](https://www.php.net/manual/en/book.opcache.php) 是否已安装、启用并正确配置
 - 启用 [Composer 自动加载器优化](https://getcomposer.org/doc/articles/autoloader-optimization.md)
 - 确保 `realpath` 缓存对于你的应用程序需求足够大
-- 使用[预加载](https://www.php.net/manual/zh/opcache.preloading.php)
+- 使用[预加载](https://www.php.net/manual/en/opcache.preloading.php)
 
 有关更多详细信息，请阅读[专门的 Symfony 文档条目](https://symfony.com/doc/current/performance.html)
 （即使你不使用 Symfony，大多数提示也很有用）。
+
+## 拆分线程池
+
+应用程序与慢速外部服务交互是很常见的，例如在高负载下往往不可靠或持续需要 10 秒以上才能响应的 API。
+在这种情况下，将线程池拆分以拥有专用的“慢速”池可能会很有益。这可以防止慢速端点消耗所有服务器资源/线程，并限制指向慢速端点的请求并发性，类似于连接池。
+
+```caddyfile
+example.com {
+    php_server {
+        root /app/public # 你的应用程序根目录
+        worker index.php {
+            match /slow-endpoint/* # 所有路径为 /slow-endpoint/* 的请求都由这个线程池处理
+            num 1 # 匹配 /slow-endpoint/* 的请求至少有 1 个线程
+            max_threads 20 # 如果需要，允许最多 20 个线程处理匹配 /slow-endpoint/* 的请求
+        }
+        worker index.php {
+            match * # 所有其他请求单独处理
+            num 1 # 其他请求至少有 1 个线程，即使慢速端点开始挂起
+            max_threads 20 # 如果需要，允许最多 20 个线程处理其他请求
+        }
+    }
+}
+```
+
+通常，也建议通过使用消息队列等相关机制，异步处理非常慢的端点。

docs/fr/performance.md

@@ -5,26 +5,26 @@ Cependant, il est possible d'améliorer considérablement les performances en ut
 
 ## Nombre de threads et de workers
 
-Par défaut, FrankenPHP démarre deux fois plus de threads et de workers (en mode worker) que le nombre de CPU disponibles.
+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.
 
 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.
-Nous recommandons vivement de modifier ces valeurs.
+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`.
 
-Pour trouver les bonnes valeurs, il est souhaitable d'effectuer des tests de charge simulant le trafic réel.
+Pour trouver les bonnes valeurs, il est préférable d'effectuer des tests de charge simulant le trafic réel.
 [k6](https://k6.io) et [Gatling](https://gatling.io) sont de bons outils pour cela.
 
 Pour configurer le nombre de threads, utilisez l'option `num_threads` des directives `php_server` et `php`.
-Pour changer le nombre de travailleurs, utilisez l'option `num` de la section `worker` de la directive `frankenphp`.
+Pour changer le nombre de workers, utilisez l'option `num` de la section `worker` de la directive `frankenphp`.
 
 ### `max_threads`
 
 Bien qu'il soit toujours préférable de savoir exactement à quoi ressemblera votre trafic, les applications réelles
-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.
+ont tendance à être plus imprévisibles. La [configuration](config.md#caddyfile-config) `max_threads` permet à FrankenPHP de créer automatiquement des threads supplémentaires au moment de l'exécution, jusqu'à la limite spécifiée.
 `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.
 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,
 `auto` prendra par défaut 2x `num_threads`. Gardez à l'esprit que `auto` peut fortement sous-estimer le nombre de threads nécessaires.
 `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
-processus et les délègue automatiquement à différents scripts de travail et au `mode classique` selon les besoins.
+processus et les délègue automatiquement à différents scripts worker et au 'mode classique' selon les besoins.
 
 ## Mode worker
 
@@ -34,18 +34,18 @@ vous devez créer un script worker et vous assurer que l'application n'a pas de
 
 ## Ne pas utiliser musl
 
-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).
+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).
 
-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,
-surtout lorsqu'il est compilé en mode ZTS (_thread-safe_), ce qui est nécessaire pour FrankenPHP.
+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,
+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é.
 
 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).
 
-Dans les environnements de production, nous recommandons fortement d'utiliser la glibc.
+Dans les environnements de production, nous recommandons d'utiliser FrankenPHP lié à glibc, compilé avec un niveau d'optimisation approprié.
 
-Cela peut être réalisé en utilisant les images Docker Debian (par défaut) et [en compilant FrankenPHP à partir des sources](compile.md).
+Cela peut être réalisé en utilisant les images Docker Debian, en utilisant [nos paquets .deb, .rpm ou .apk maintenus](https://pkgs.henderkes.com), ou en [compilant FrankenPHP à partir des sources](compile.md).
 
-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).
+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.
 
 ## Configuration du runtime Go
 
@@ -84,15 +84,27 @@ vous pouvez les désactiver en définissant explicitement `try_files` comme ceci
 ```caddyfile
 php_server {
     try_files {path} index.php
-    root /root/to/your/app #  l'ajout explicite de la racine ici permet une meilleure mise en cache
+    root /root/to/your/app # l'ajout explicite de la racine ici permet une meilleure mise en cache
 }
 ```
 
 Cela permet de réduire considérablement le nombre d'opérations inutiles sur les fichiers.
+Un équivalent worker de la configuration précédente serait :
+
+```caddyfile
+route {
+    php_server { # utilisez "php" au lieu de "php_server" si vous n'avez pas du tout besoin du serveur de fichiers
+        root /root/to/your/app
+        worker /path/to/worker.php {
+            match * # envoie toutes les requêtes directement au worker
+        }
+    }
+}
+```
 
 Une approche alternative avec 0 opérations inutiles sur le système de fichiers serait d'utiliser la directive `php`
 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.
-Un exemple de [configuration](config.md#configuration-du-caddyfile) qui sert des fichiers statiques derrière un dossier `/assets` pourrait ressembler à ceci :
+Un exemple de [configuration](config.md#caddyfile-config) qui sert des fichiers statiques derrière un dossier `/assets` pourrait ressembler à ceci :
 
 ```caddyfile
 route {
@@ -105,10 +117,10 @@ route {
         root /root/to/your/app
     }
 
-    #  tout ce qui n'est pas dans /assets est géré par votre index ou votre fichier PHP worker
+    # tout ce qui n'est pas dans /assets est géré par votre fichier PHP d'index ou worker
     rewrite index.php
     php {
-        root /root/to/your/app #  l'ajout explicite de la racine ici permet une meilleure mise en cache
+        root /root/to/your/app # l'ajout explicite de la racine ici permet une meilleure mise en cache
     }
 }
 ```
@@ -155,3 +167,32 @@ En particulier :
 
 Pour plus de détails, lisez [l'entrée de la documentation dédiée de Symfony](https://symfony.com/doc/current/performance.html)
 (la plupart des conseils sont utiles même si vous n'utilisez pas Symfony).
+
+## Division du pool de threads
+
+Il est courant que les applications interagissent avec des services externes lents, comme une
+API qui a tendance à être peu fiable sous forte charge ou qui met constamment plus de 10 secondes à répondre.
+Dans de tels cas, il peut être bénéfique de diviser le pool de threads pour avoir des pools "lents" dédiés.
+Cela empêche les points d'accès lents de consommer toutes les ressources/threads du serveur et
+limite la concurrence des requêtes se dirigeant vers le point d'accès lent, à l'instar d'un
+pool de connexions.
+
+```caddyfile
+example.com {
+    php_server {
+        root /app/public # la racine de votre application
+        worker index.php {
+            match /slow-endpoint/* # toutes les requêtes avec le chemin /slow-endpoint/* sont gérées par ce pool de threads
+            num 1 # minimum 1 thread pour les requêtes correspondant à /slow-endpoint/*
+            max_threads 20 # autorise jusqu'à 20 threads pour les requêtes correspondant à /slow-endpoint/*, si nécessaire
+        }
+        worker index.php {
+            match * # toutes les autres requêtes sont gérées séparément
+            num 1 # minimum 1 thread pour les autres requêtes, même si les points d'accès lents commencent à bloquer
+            max_threads 20 # autorise jusqu'à 20 threads pour les autres requêtes, si nécessaire
+        }
+    }
+}
+```
+
+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.

docs/ja/performance.md

@@ -43,9 +43,9 @@ PHPは、従来のGNUライブラリの代わりにこの代替Cライブラリ
 
 本番環境では、glibcにリンクされたFrankenPHPを使用することをお勧めします。
 
-これは、Debian Dockerイメージ（デフォルト）を使用するか、[リリースページ](https://github.com/php/frankenphp/releases)から -gnu サフィックス付きバイナリをダウンロードするか、あるいは[FrankenPHPをソースからコンパイル](compile.md)することで実現できます。
+これは、Debian Dockerイメージを使用するか、[公式パッケージ (.deb, .rpm, .apk)](https://pkgs.henderkes.com) を使用するか、あるいは[FrankenPHPをソースからコンパイル](compile.md)することで実現できます。
 
-または、[mimalloc allocator](https://github.com/microsoft/mimalloc)でコンパイルされた静的muslバイナリも提供しており、これによりスレッド環境での問題を軽減できます。
+より軽量で安全なコンテナのためには、Alpineよりも[強化されたDebianイメージ](docker.md#hardening-images)を検討することをお勧めします。
 
 ## Go Runtime設定
 
@@ -89,6 +89,18 @@ php_server {
 ```
 
 これにより、不要なファイルの操作の回数を大幅に削減できます。
+上記の構成をワーカーモードに相当させると、次のようになります:
+
+```caddyfile
+route {
+    php_server { # file server が全く不要な場合は "php_server" の代わりに "php" を使用します
+        root /root/to/your/app
+        worker /path/to/worker.php {
+            match * # すべてのリクエストを直接ワーカーに送信します
+        }
+    }
+}
+```
 
 ファイルシステムへの不要な操作を完全にゼロにする代替アプローチとして、`php`ディレクティブを使用し、
 パスによってPHPファイルとそれ以外を分ける方法があります。アプリケーション全体が1つのエントリーファイルで提供される場合、この方法は有効です。
@@ -155,3 +167,29 @@ FrankenPHPは公式のPHPインタープリターを使用しています。
 
 詳細については、[Symfonyの専用ドキュメントエントリ](https://symfony.com/doc/current/performance.html)をお読みください
 （Symfonyを使用していなくても、多くのヒントが役立ちます）。
+
+## スレッドプールの分割
+
+アプリケーションが、高負荷時に不安定になったり、常に10秒以上応答にかかるAPIのような遅い外部サービスと連携することはよくあります。
+このような場合、スレッドプールを分割して専用の「遅い」プールを持つことが有益です。
+これにより、遅いエンドポイントがすべてのサーバーリソース/スレッドを消費するのを防ぎ、コネクションプールと同様に、遅いエンドポイントへのリクエストの同時実行数を制限できます。
+
+```caddyfile
+example.com {
+    php_server {
+        root /app/public # アプリケーションのルート
+        worker index.php {
+            match /slow-endpoint/* # パスが /slow-endpoint/* のすべてリクエストはこのスレッドプールによって処理されます
+            num 1 # /slow-endpoint/* に一致するリクエストに対しては最低1スレッド
+            max_threads 20 # 必要に応じて、/slow-endpoint/* に一致するリクエストに対して最大20スレッドまで許可します
+        }
+        worker index.php {
+            match * # 他のすべてのリクエストは個別に処理されます
+            num 1 # 遅いエンドポイントがハングし始めても、他のリクエストには最低1スレッド
+            max_threads 20 # 必要に応じて、他のリクエストに対して最大20スレッドまで許可します
+        }
+    }
+}
+```
+
+一般的に、メッセージキューなどの適切なメカニズムを使用して、非常に遅いエンドポイントを非同期的に処理することも推奨されます。