From f3b7bcc67bd6c5330127afaacfd75eaa352e5c12 Mon Sep 17 00:00:00 2001 From: AlliBalliBaba <45872305+AlliBalliBaba@users.noreply.github.com> Date: Tue, 10 Feb 2026 10:21:53 +0000 Subject: [PATCH] docs: update translations --- docs/cn/performance.md | 49 ++++++++-- docs/fr/performance.md | 73 ++++++++++---- docs/ja/performance.md | 42 +++++++- docs/pt-br/performance.md | 100 ++++++++++++------- docs/ru/config.md | 2 +- docs/ru/performance.md | 130 ++++++++++++++++++------- docs/tr/config.md | 2 +- docs/tr/performance.md | 195 ++++++++++++++++++++++++++++++++++++++ 8 files changed, 501 insertions(+), 92 deletions(-) create mode 100644 docs/tr/performance.md diff --git a/docs/cn/performance.md b/docs/cn/performance.md index ee11bb07e9..ea66cf66aa 100644 --- a/docs/cn/performance.md +++ b/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 个线程处理其他请求 + } + } +} +``` + +通常，也建议通过使用消息队列等相关机制，异步处理非常慢的端点。 diff --git a/docs/fr/performance.md b/docs/fr/performance.md index e1531624a3..483917e0af 100644 --- a/docs/fr/performance.md +++ b/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. diff --git a/docs/ja/performance.md b/docs/ja/performance.md index 5139a0347e..2bbeaecd99 100644 --- a/docs/ja/performance.md +++ b/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スレッドまで許可します + } + } +} +``` + +一般的に、メッセージキューなどの適切なメカニズムを使用して、非常に遅いエンドポイントを非同期的に処理することも推奨されます。 diff --git a/docs/pt-br/performance.md b/docs/pt-br/performance.md index 8b825be99e..356a07fb8f 100644 --- a/docs/pt-br/performance.md +++ b/docs/pt-br/performance.md @@ -5,15 +5,14 @@ facilidade de uso. No entanto, é possível melhorar substancialmente o desempenho usando uma configuração apropriada. -## Número de threads e workers +## Número de Threads e Workers Por padrão, o FrankenPHP inicia 2 vezes mais threads e workers (no modo worker) -do que a quantidade de CPU disponível. +do que o número de núcleos de CPU disponíveis. Os valores apropriados dependem muito de como sua aplicação foi escrita, do que ela faz e do seu hardware. -Recomendamos fortemente alterar esses valores. -Para melhor estabilidade do sistema, recomenda-se ter `num_threads` x +Recomendamos fortemente alterar esses valores. Para melhor estabilidade do sistema, recomenda-se ter `num_threads` x `memory_limit` < `available_memory`. Para encontrar os valores corretos, é melhor executar testes de carga simulando @@ -30,22 +29,22 @@ diretiva `frankenphp`. Embora seja sempre melhor saber exatamente como será o seu tráfego, aplicações reais tendem a ser mais imprevisíveis. -A [configuração](config.md#configuracao-do-caddyfile) `max_threads` permite que +A [configuração](config.md#caddyfile-config) `max_threads` permite que o FrankenPHP crie threads adicionais automaticamente em tempo de execução até o limite especificado. `max_threads` pode ajudar você a descobrir quantas threads são necessárias para lidar com seu tráfego e pode tornar o servidor mais resiliente a picos de latência. Se definido como `auto`, o limite será estimado com base no `memory_limit` em -seu `php.ini`. -Caso contrário, `auto` assumirá como padrão o valor 2x `num_threads`. +seu `php.ini`. Se não for possível fazer isso, +`auto` assumirá como padrão 2x `num_threads`. Lembre-se de que `auto` pode subestimar bastante o número de threads necessárias. `max_threads` é semelhante ao [pm.max_children](https://www.php.net/manual/pt_BR/install.fpm.configuration.php#pm.max-children) do PHP FPM. A principal diferença é que o FrankenPHP usa threads em vez de processos e as -delega automaticamente entre diferentes worker scripts e o modo clássico, +delega automaticamente entre diferentes worker scripts e o 'classic mode', conforme necessário. ## Modo worker @@ -55,31 +54,28 @@ aplicação precisa ser adaptada para ser compatível com este modo: você preci criar um worker script e garantir que a aplicação não esteja com vazamento de memória. -## Não use `musl` +## Não use musl A variante Alpine Linux das imagens oficiais do Docker e os binários padrão que -fornecemos usam [a biblioteca C `musl`](https://musl.libc.org). +fornecemos usam [a biblioteca C musl](https://musl.libc.org). O PHP é conhecido por ser -[mais lento](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14381) +[mais lento](https://gitlab.alpinux.org/alpine/aports/-/issues/14381) ao usar esta biblioteca C alternativa em vez da biblioteca GNU tradicional, especialmente quando compilado no modo ZTS (thread-safe), necessário para o -FrankenPHP. -A diferença pode ser significativa em um ambiente com muitas threads. +FrankenPHP. A diferença pode ser significativa em um ambiente com muitas threads. Além disso, -[alguns bugs só acontecem ao usar `musl`](https://github.com/php/php-src/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+label%3ABug+musl). +[alguns bugs só acontecem ao usar musl](https://github.com/php/php-src/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+label%3ABug+musl). -Em ambientes de produção, recomendamos o uso do FrankenPHP vinculado à `glibc`. +Em ambientes de produção, recomendamos o uso do FrankenPHP vinculado à glibc, compilado com um nível de otimização apropriado. -Isso pode ser feito usando as imagens Docker do Debian (o padrão), baixando o -binário com sufixo -gnu de nossos -[Lançamentos](https://github.com/php/frankenphp/releases) ou +Isso pode ser feito usando as imagens Docker do Debian, usando +[nossos pacotes .deb, .rpm ou .apk dos mantenedores](https://pkgs.henderkes.com), ou [compilando o FrankenPHP a partir do código-fonte](compile.md). -Como alternativa, fornecemos binários `musl` estáticos compilados com -[o alocador `mimalloc`](https://github.com/microsoft/mimalloc), o que alivia os -problemas em cenários com threads. +Para contêineres mais leves ou seguros, você pode considerar +[uma imagem Debian reforçada](docker.md#hardening-images) em vez de Alpine. ## Configuração do runtime do Go @@ -116,28 +112,39 @@ php_server { ## `try_files` Além de arquivos estáticos e arquivos PHP, `php_server` também tentará servir o -arquivo index da sua aplicação e os arquivos index de diretório (`/path/` -> +arquivo de índice da sua aplicação e os arquivos de índice de diretório (`/path/` -> `/path/index.php`). -Se você não precisa de arquivos index de diretório, pode desativá-los definindo +Se você não precisa de arquivos de índice de diretório, pode desativá-los definindo explicitamente `try_files` assim: ```caddyfile php_server { try_files {path} index.php - root /raiz/da/sua/aplicacao # adicionar explicitamente a raiz aqui permite um melhor armazenamento em cache + root /root/to/your/app # adicionar explicitamente o root aqui permite um melhor cache } ``` Isso pode reduzir significativamente o número de operações desnecessárias com arquivos. +Um equivalente no modo worker da configuração anterior seria: + +```caddyfile +route { + php_server { # use "php" em vez de "php_server" se você não precisar do servidor de arquivos + root /root/to/your/app + worker /path/to/worker.php { + match * # envia todas as requisições diretamente para o worker + } + } +} +``` Uma abordagem alternativa com 0 operações desnecessárias no sistema de arquivos -seria usar a diretiva `php` e separar os arquivos estáticos do PHP usando -caminhos. +seria usar a diretiva `php` e dividir os arquivos estáticos dos arquivos PHP por caminho. Essa abordagem funciona bem se toda a sua aplicação for servida por um arquivo de entrada. -Um exemplo de [configuração](config.md#configuracao-do-caddyfile) que serve -arquivos estáticos a partir de uma pasta `/assets` poderia ser assim: +Um exemplo de [configuração](config.md#caddyfile-config) que serve +arquivos estáticos atrás de uma pasta `/assets` poderia ser assim: ```caddyfile route { @@ -145,15 +152,15 @@ route { path /assets/* } - # tudo a partir de /assets é gerenciado pelo servidor de arquivos + # tudo o que está em /assets é gerenciado pelo servidor de arquivos file_server @assets { - root /raiz/da/sua/aplicacao + root /root/to/your/app } - # tudo o que não está em /assets é gerenciado pelo seu arquivo index ou worker PHP + # tudo o que não está em /assets é gerenciado pelo seu arquivo de índice ou worker PHP rewrite index.php php { - root /raiz/da/sua/aplicacao # adicionar explicitamente a raiz aqui permite um melhor armazenamento em cache + root /root/to/your/app # adicionar explicitamente o root aqui permite um melhor cache } } ``` @@ -213,3 +220,32 @@ Em particular: Para mais detalhes, leia [a entrada dedicada na documentação do Symfony](https://symfony.com/doc/current/performance.html) (a maioria das dicas é útil mesmo se você não usa o Symfony). + +## Dividindo o Pool de Threads + +É comum que aplicações interajam com serviços externos lentos, como uma +API que tende a ser instável sob alta carga ou que consistentemente leva mais de 10 segundos para responder. +Nesses casos, pode ser benéfico dividir o pool de threads para ter pools "lentos" dedicados. +Isso impede que os endpoints lentos consumam todos os recursos/threads do servidor e +limita a concorrência de requisições direcionadas ao endpoint lento, semelhante a um +pool de conexões. + +```caddyfile +example.com { + php_server { + root /app/public # a raiz da sua aplicação + worker index.php { + match /slow-endpoint/* # todas as requisições com caminho /slow-endpoint/* são tratadas por este pool de threads + num 1 # mínimo de 1 thread para requisições que correspondem a /slow-endpoint/* + max_threads 20 # permite até 20 threads para requisições que correspondem a /slow-endpoint/*, se necessário + } + worker index.php { + match * # todas as outras requisições são tratadas separadamente + num 1 # mínimo de 1 thread para outras requisições, mesmo que os endpoints lentos comecem a travar + max_threads 20 # permite até 20 threads para outras requisições, se necessário + } + } +} +``` + +Geralmente, também é aconselhável lidar com endpoints muito lentos de forma assíncrona, usando mecanismos relevantes como filas de mensagens. diff --git a/docs/ru/config.md b/docs/ru/config.md index 7a2c25ba66..e01c046bf4 100644 --- a/docs/ru/config.md +++ b/docs/ru/config.md @@ -1,4 +1,4 @@ -# Конфигурация +# Конфигурация FrankenPHP, Caddy, а также модули Mercure и Vulcain могут быть настроены с использованием [конфигурационных форматов, поддерживаемых Caddy](https://caddyserver.com/docs/getting-started#your-first-config). diff --git a/docs/ru/performance.md b/docs/ru/performance.md index 06e4a52455..51bb06df41 100644 --- a/docs/ru/performance.md +++ b/docs/ru/performance.md @@ -1,52 +1,50 @@ # Производительность -По умолчанию FrankenPHP предлагает хороший баланс между производительностью и удобством использования. -Однако, используя подходящую конфигурацию, можно существенно улучшить производительность. +По умолчанию FrankenPHP стремится предложить хороший компромисс между производительностью и простотой использования. Однако, используя подходящую конфигурацию, можно существенно улучшить производительность. -## Количество потоков и worker-скриптов +## Количество потоков и воркеров -По умолчанию FrankenPHP запускает потоков и worker-скриптов (в worker режиме) вдвое больше, чем количество доступных процессорных ядер. +По умолчанию FrankenPHP запускает в 2 раза больше потоков и воркеров (в режиме воркера), чем доступное количество ядер процессора. -Оптимальные значения зависят от структуры вашего приложения, его функциональности и аппаратного обеспечения. -Мы настоятельно рекомендуем изменить эти значения. +Подходящие значения сильно зависят от того, как написано ваше приложение, что оно делает, и от вашего оборудования. Мы настоятельно рекомендуем изменить эти значения. Для лучшей стабильности системы рекомендуется, чтобы `num_threads` x `memory_limit` < `available_memory`. -Чтобы найти подходящие параметры, лучше всего провести нагрузочные тесты, имитирующие реальный трафик. -Хорошими инструментами для этого являются [k6](https://k6.io) и [Gatling](https://gatling.io). +Чтобы найти подходящие значения, лучше всего провести нагрузочные тесты, имитирующие реальный трафик. [k6](https://k6.io) и [Gatling](https://gatling.io) являются хорошими инструментами для этого. -Чтобы настроить количество потоков, используйте опцию `num_threads` в директивах `php_server` и `php`. -Для изменения количества worker-скриптов используйте опцию `num` в секции `worker` директивы `frankenphp`. +Чтобы настроить количество потоков, используйте опцию `num_threads` директив `php_server` и `php`. Для изменения количества воркеров используйте опцию `num` секции `worker` директивы `frankenphp`. -## Worker режим +### `max_threads` -Включение [Worker режима](worker.md) значительно улучшает производительность, -но ваше приложение должно быть адаптировано для совместимости с этим режимом: -необходимо создать worker-скрипт и убедиться, что приложение не имеет утечек памяти. +Хотя всегда лучше точно знать, как будет выглядеть ваш трафик, реальные приложения, как правило, более непредсказуемы. [Конфигурация](config.md#caddyfile-config) `max_threads` позволяет FrankenPHP автоматически создавать дополнительные потоки во время выполнения до указанного предела. `max_threads` может помочь вам определить, сколько потоков требуется для обработки вашего трафика, и может сделать сервер более устойчивым к скачкам задержки. Если установлено значение `auto`, лимит будет оценен на основе `memory_limit` в вашем `php.ini`. Если это невозможно, `auto` вместо этого будет по умолчанию равно 2x `num_threads`. Имейте в виду, что `auto` может сильно недооценивать необходимое количество потоков. `max_threads` похожа на [pm.max_children](https://www.php.net/manual/en/install.fpm.configuration.php#pm.max-children) в PHP FPM. Основное отличие состоит в том, что FrankenPHP использует потоки вместо процессов и автоматически распределяет их между различными скриптами воркеров и 'классическим режимом' по мере необходимости. + +## Режим воркера + +Включение [режима воркера](worker.md) значительно улучшает производительность, но ваше приложение должно быть адаптировано для совместимости с этим режимом: необходимо создать скрипт воркера и убедиться, что приложение не имеет утечек памяти. ## Избегайте использования musl -Статические бинарники, которые мы предоставляем, а также Alpine Linux-вариант официальных Docker-образов используют [библиотеку musl libc](https://musl.libc.org). +Вариант официальных Docker-образов для Alpine Linux и предоставляемые нами бинарные файлы по умолчанию используют [библиотеку musl libc](https://musl.libc.org). -Известно, что PHP [значительно медленнее работает](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14381) с этой библиотекой по сравнению с традиционной GNU libc, особенно при компиляции в ZTS режиме (потокобезопасный режим), который требуется для FrankenPHP. +Известно, что PHP [работает медленнее](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14381) при использовании этой альтернативной библиотеки C вместо традиционной библиотеки GNU, особенно при компиляции в режиме ZTS (потокобезопасном режиме), который требуется для FrankenPHP. Разница может быть существенной в сильно многопоточной среде. Кроме того, [некоторые ошибки проявляются исключительно при использовании musl](https://github.com/php/php-src/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+label%3ABug+musl). -В производственной среде настоятельно рекомендуется использовать glibc. +В производственных средах мы рекомендуем использовать FrankenPHP, скомпилированный с glibc и с соответствующим уровнем оптимизации. -Это можно сделать, используя Debian Docker-образы (по умолчанию) и [компилируя FrankenPHP из исходников](compile.md). +Этого можно достичь, используя Docker-образы Debian, используя [пакеты .deb, .rpm или .apk от наших мейнтейнеров](https://pkgs.henderkes.com) или [компилируя FrankenPHP из исходников](compile.md). -В качестве альтернативы мы предоставляем статические бинарники, скомпилированные с [аллокатором mimalloc](https://github.com/microsoft/mimalloc), что делает FrankenPHP+musl быстрее (но всё же медленнее, чем FrankenPHP+glibc). +Для более компактных или безопасных контейнеров вы можете рассмотреть [усиленный образ Debian](docker.md#hardening-images) вместо Alpine. ## Настройка среды выполнения Go FrankenPHP написан на языке Go. -В большинстве случаев среда выполнения Go не требует особой настройки, но в некоторых ситуациях специфическая конфигурация может улучшить производительность. +В целом, среда выполнения Go не требует какой-либо особой настройки, но при определенных обстоятельствах специфическая конфигурация улучшает производительность. -Рекомендуется установить переменную окружения `GODEBUG` в значение `cgocheck=0` (по умолчанию в Docker-образах FrankenPHP). +Вероятно, вы захотите установить переменную окружения `GODEBUG` в значение `cgocheck=0` (по умолчанию в Docker-образах FrankenPHP). -Если вы запускаете FrankenPHP в контейнерах (Docker, Kubernetes, LXC и т.д.) и ограничиваете доступную память, установите переменную окружения `GOMEMLIMIT` в значение доступного объёма памяти. +Если вы запускаете FrankenPHP в контейнерах (Docker, Kubernetes, LXC...) и ограничиваете память, доступную для контейнеров, установите переменную окружения `GOMEMLIMIT` в значение доступного объёма памяти. -Для более детальной информации ознакомьтесь с [документацией Go по этой теме](https://pkg.go.dev/runtime#hdr-Environment_Variables). +Для получения более подробной информации [страница документации Go, посвященная этой теме](https://pkg.go.dev/runtime#hdr-Environment_Variables), обязательна к прочтению, чтобы максимально эффективно использовать среду выполнения. ## `file_server` @@ -60,17 +58,60 @@ php_server { } ``` +## `try_files` + +Помимо статических файлов и файлов PHP, `php_server` также попытается обслужить индекс вашего приложения и индексные файлы директорий (`/path/` -> `/path/index.php`). Если вам не нужны индексы директорий, вы можете отключить их, явно определив `try_files` следующим образом: + +```caddyfile +php_server { + try_files {path} index.php + root /root/to/your/app # explicitly adding the root here allows for better caching +} +``` + +Это может значительно сократить количество ненужных файловых операций. Эквивалент предыдущей конфигурации для воркера будет следующим: + +```caddyfile +route { + php_server { # use "php" instead of "php_server" if you don't need the file server at all + root /root/to/your/app + worker /path/to/worker.php { + match * # send all requests directly to the worker + } + } +} +``` + +Альтернативный подход с 0 ненужных операций файловой системы заключается в использовании директивы `php` и разделении файлов от PHP по пути. Этот подход хорошо работает, если все ваше приложение обслуживается одним входным файлом. Пример [конфигурации](config.md#caddyfile-config), которая обслуживает статические файлы за папкой `/assets`, может выглядеть так: + +```caddyfile +route { + @assets { + path /assets/* + } + + # everything behind /assets is handled by the file server + file_server @assets { + root /root/to/your/app + } + + # everything that is not in /assets is handled by your index or worker PHP file + rewrite index.php + php { + root /root/to/your/app # explicitly adding the root here allows for better caching + } +} +``` + ## Плейсхолдеры -Вы можете использовать [плейсхолдеры](https://caddyserver.com/docs/conventions#placeholders) в директивах `root` и `env`. -Однако это предотвращает кеширование значений и существенно снижает производительность. +Вы можете использовать [плейсхолдеры](https://caddyserver.com/docs/conventions#placeholders) в директивах `root` и `env`. Однако это предотвращает кеширование значений и существенно снижает производительность. По возможности избегайте использования плейсхолдеров в этих директивах. ## `resolve_root_symlink` -По умолчанию, если корневая директория документа является символьной ссылкой, она автоматически разрешается FrankenPHP (это необходимо для корректной работы PHP). -Если корневая директория документа не является символьной ссылкой, вы можете отключить эту функцию. +По умолчанию, если корневая директория документа является символьной ссылкой, она автоматически разрешается FrankenPHP (это необходимо для корректной работы PHP). Если корневая директория документа не является символьной ссылкой, вы можете отключить эту функцию. ```caddyfile php_server { @@ -78,18 +119,15 @@ php_server { } ``` -Это улучшит производительность, если директива `root` содержит [плейсхолдеры](https://caddyserver.com/docs/conventions#placeholders). -В остальных случаях прирост производительности будет минимальным. +Это улучшит производительность, если директива `root` содержит [плейсхолдеры](https://caddyserver.com/docs/conventions#placeholders). В остальных случаях прирост производительности будет минимальным. ## Логи -Логирование, безусловно, полезно, но требует операций ввода-вывода и выделения памяти, что значительно снижает производительность. -Убедитесь, что вы [правильно настроили уровень логирования](https://caddyserver.com/docs/caddyfile/options#log) и логируете только необходимое. +Логирование, безусловно, очень полезно, но, по определению, оно требует операций ввода-вывода и выделения памяти, что значительно снижает производительность. Убедитесь, что вы [правильно настроили уровень логирования](https://caddyserver.com/docs/caddyfile/options#log) и логируете только то, что необходимо. ## Производительность PHP -FrankenPHP использует официальный интерпретатор PHP. -Все стандартные оптимизации производительности PHP применимы к FrankenPHP. +FrankenPHP использует официальный интерпретатор PHP. Все обычные оптимизации производительности, связанные с PHP, применимы к FrankenPHP. В частности: @@ -98,4 +136,28 @@ FrankenPHP использует официальный интерпретато - убедитесь, что кеш `realpath` достаточно велик для нужд вашего приложения; - используйте [предварительную загрузку](https://www.php.net/manual/en/opcache.preloading.php). -Для более детальной информации ознакомьтесь с [документацией Symfony о производительности](https://symfony.com/doc/current/performance.html) (большинство советов полезны даже если вы не используете Symfony). +Для получения более подробной информации ознакомьтесь с [разделом документации Symfony, посвященным производительности](https://symfony.com/doc/current/performance.html) (большинство советов полезны, даже если вы не используете Symfony). + +## Разделение пула потоков + +Приложениям часто приходится взаимодействовать с медленными внешними службами, такими как API, который имеет тенденцию быть ненадежным при высокой нагрузке или постоянно отвечает в течение 10+ секунд. В таких случаях может быть полезно разделить пул потоков, чтобы иметь выделенные "медленные" пулы. Это предотвращает потребление медленными конечными точками всех ресурсов/потоков сервера и ограничивает параллелизм запросов, направляемых к медленной конечной точке, подобно пулу соединений. + +```caddyfile +example.com { + php_server { + root /app/public # the root of your application + worker index.php { + match /slow-endpoint/* # all requests with path /slow-endpoint/* are handled by this thread pool + num 1 # minimum 1 threads for requests matching /slow-endpoint/* + max_threads 20 # allow up to 20 threads for requests matching /slow-endpoint/*, if needed + } + worker index.php { + match * # all other requests are handled separately + num 1 # minimum 1 threads for other requests, even if the slow endpoints start hanging + max_threads 20 # allow up to 20 threads for other requests, if needed + } + } +} +``` + +В целом, также рекомендуется обрабатывать очень медленные конечные точки асинхронно, используя соответствующие механизмы, такие как очереди сообщений. diff --git a/docs/tr/config.md b/docs/tr/config.md index 5d17f6e19a..4226b7c741 100644 --- a/docs/tr/config.md +++ b/docs/tr/config.md @@ -1,4 +1,4 @@ -# Konfigürasyon +# Konfigürasyon FrankenPHP, Caddy'nin yanı sıra Mercure ve Vulcain modülleri [Caddy tarafından desteklenen formatlar](https://caddyserver.com/docs/getting-started#your-first-config) kullanılarak yapılandırılabilir. diff --git a/docs/tr/performance.md b/docs/tr/performance.md new file mode 100644 index 0000000000..a7b72335b1 --- /dev/null +++ b/docs/tr/performance.md @@ -0,0 +1,195 @@ +# Performans + +Varsayılan olarak, FrankenPHP performans ve kullanım kolaylığı arasında iyi bir denge sunmaya çalışır. +Ancak, uygun bir yapılandırma kullanılarak performansı önemli ölçüde artırmak mümkündür. + +## İş Parçacığı ve İşçi Sayısı + +Varsayılan olarak, FrankenPHP mevcut CPU çekirdeği sayısının 2 katı kadar iş parçacığı ve işçi (işçi modunda) başlatır. + +Uygun değerler, uygulamanızın nasıl yazıldığına, ne yaptığına ve donanımınıza büyük ölçüde bağlıdır. +Bu değerleri değiştirmenizi şiddetle tavsiye ederiz. En iyi sistem kararlılığı için, `num_threads` x `memory_limit` < `available_memory` olması önerilir. + +Doğru değerleri bulmak için gerçek trafiği simüle eden yük testleri yapmak en iyisidir. +[k6](https://k6.io) ve [Gatling](https://gatling.io) bunun için iyi araçlardır. + +İş parçacığı sayısını yapılandırmak için `php_server` ve `php` yönergelerinin `num_threads` seçeneğini kullanın. +İşçi sayısını değiştirmek için `frankenphp` yönergesinin `worker` bölümünün `num` seçeneğini kullanın. + +### `max_threads` + +Trafiğinizin neye benzeyeceğini tam olarak bilmek her zaman daha iyi olsa da, gerçek dünya uygulamaları daha +tahmin edilemez olma eğilimindedir. `max_threads` [yapılandırması](config.md#caddyfile-config), FrankenPHP'nin çalışma zamanında belirtilen sınıra kadar ek iş parçacıkları otomatik olarak oluşturmasına olanak tanır. +`max_threads`, trafiğinizi yönetmek için kaç iş parçacığına ihtiyacınız olduğunu anlamanıza yardımcı olabilir ve sunucuyu gecikme artışlarına karşı daha dirençli hale getirebilir. +Eğer `auto` olarak ayarlanırsa, sınır `php.ini` dosyanızdaki `memory_limit` değerine göre tahmin edilecektir. Bunu yapamazsa, +`auto` bunun yerine varsayılan olarak 2x `num_threads` olacaktır. `auto`'nun ihtiyaç duyulan iş parçacığı sayısını büyük ölçüde küçümseyebileceğini unutmayın. +`max_threads`, PHP FPM'nin [pm.max_children](https://www.php.net/manual/en/install.fpm.configuration.php#pm.max-children) ile benzerdir. Temel fark, FrankenPHP'nin süreçler yerine +iş parçacıkları kullanması ve gerektiğinde bunları farklı işçi komut dosyaları ve 'klasik mod' arasında otomatik olarak devretmesidir. + +## İşçi Modu + +[İşçi modunu](worker.md) etkinleştirmek performansı önemli ölçüde artırır, +ancak uygulamanızın bu modla uyumlu olacak şekilde uyarlanması gerekir: +bir işçi komut dosyası oluşturmanız ve uygulamanın bellek sızdırmadığından emin olmanız gerekir. + +## musl Kullanmayın + +Resmi Docker imajlarının Alpine Linux varyantı ve sağladığımız varsayılan ikili dosyalar [musl libc](https://musl.libc.org) kullanmaktadır. + +PHP'nin, geleneksel GNU kitaplığı yerine bu alternatif C kitaplığını kullandığında [daha yavaş olduğu](https://gitlab.alpinelinux.org/alpine/aports/-/issues/14381) bilinmektedir, +özellikle de FrankenPHP için gerekli olan ZTS modunda (iş parçacığı güvenli) derlendiğinde. Fark, yoğun iş parçacıklı bir ortamda önemli olabilir. + +Ayrıca, [bazı hatalar yalnızca musl kullanıldığında ortaya çıkar](https://github.com/php/php-src/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+label%3ABug+musl). + +Üretim ortamlarında, glibc'ye bağlı, uygun bir optimizasyon seviyesiyle derlenmiş FrankenPHP kullanmanızı öneririz. + +Bu, Debian Docker imajlarını kullanarak, [bakımcılarımızın .deb, .rpm veya .apk paketlerini](https://pkgs.henderkes.com) kullanarak veya [FrankenPHP'yi kaynak koddan derleyerek](compile.md) başarılabilir. + +Daha yalın veya daha güvenli konteynerler için Alpine yerine [güçlendirilmiş bir Debian imajı](docker.md#hardening-images) kullanmayı düşünebilirsiniz. + +## Go Çalışma Zamanı Yapılandırması + +FrankenPHP Go ile yazılmıştır. + +Genel olarak, Go çalışma zamanı özel bir yapılandırma gerektirmez, ancak belirli durumlarda, +özel yapılandırma performansı artırır. + +Muhtemelen `GODEBUG` ortam değişkenini `cgocheck=0` olarak ayarlamak isteyeceksiniz (FrankenPHP Docker imajlarındaki varsayılan değer). + +FrankenPHP'yi konteynerlerde (Docker, Kubernetes, LXC...) çalıştırıyorsanız ve konteynerler için ayrılan belleği sınırlıyorsanız, +`GOMEMLIMIT` ortam değişkenini mevcut bellek miktarına ayarlayın. + +Daha fazla ayrıntı için, [Go dokümantasyon sayfasının bu konuya ayrılmış bölümünü](https://pkg.go.dev/runtime#hdr-Environment_Variables) okumanız, çalışma zamanından en iyi şekilde yararlanmak için zorunludur. + +## `file_server` + +Varsayılan olarak, `php_server` yönergesi, +kök dizinde depolanan statik dosyaları (varlıkları) sunmak için otomatik olarak bir dosya sunucusu kurar. + +Bu özellik kullanışlıdır, ancak bir maliyeti vardır. +Bunu devre dışı bırakmak için aşağıdaki yapılandırmayı kullanın: + +```caddyfile +php_server { + file_server off +} +``` + +## `try_files` + +Statik dosyalar ve PHP dosyaları dışında, `php_server` uygulamanızın dizin dizini ve dizin dizini dosyalarını (`/path/` -> `/path/index.php`) da sunmaya çalışacaktır. Dizin dizinlerine ihtiyacınız yoksa, +`try_files` değerini açıkça şu şekilde tanımlayarak bunları devre dışı bırakabilirsiniz: + +```caddyfile +php_server { + try_files {path} index.php + root /root/to/your/app # kökü buraya açıkça eklemek daha iyi önbelleğe alma sağlar +} +``` + +Bu, gereksiz dosya işlemlerinin sayısını önemli ölçüde azaltabilir. +Önceki yapılandırmanın bir işçi eşdeğeri şöyle olacaktır: + +```caddyfile +route { + php_server { # dosya sunucusuna hiç ihtiyacınız yoksa "php_server" yerine "php" kullanın + root /root/to/your/app + worker /path/to/worker.php { + match * # tüm istekleri doğrudan işçiye gönder + } + } +} +``` + +0 gereksiz dosya sistemi işlemiyle alternatif bir yaklaşım, bunun yerine `php` yönergesini kullanmak ve dosyaları PHP'den yola göre ayırmaktır. Bu yaklaşım, tüm uygulamanızın tek bir giriş dosyası tarafından sunulması durumunda iyi çalışır. +Statik dosyaları bir `/assets` klasörünün arkasında sunan bir örnek [yapılandırma](config.md#caddyfile-config) şöyle görünebilir: + +```caddyfile +route { + @assets { + path /assets/* + } + + # /assets arkasındaki her şey dosya sunucusu tarafından işlenir + file_server @assets { + root /root/to/your/app + } + + # /assets içinde olmayan her şey dizininiz veya işçi PHP dosyanız tarafından işlenir + rewrite index.php + php { + root /root/to/your/app # kökü buraya açıkça eklemek daha iyi önbelleğe alma sağlar + } +} +``` + +## Yer Tutucular + +`root` ve `env` yönergelerinde [yer tutucular](https://caddyserver.com/docs/conventions#placeholders) kullanabilirsiniz. +Ancak bu, bu değerlerin önbelleğe alınmasını engeller ve önemli bir performans maliyetiyle birlikte gelir. + +Mümkünse, bu yönergelerde yer tutuculardan kaçının. + +## `resolve_root_symlink` + +Varsayılan olarak, belge kökü sembolik bir bağlantıysa, FrankenPHP tarafından otomatik olarak çözümlenir (PHP'nin düzgün çalışması için bu gereklidir). +Belge kökü bir sembolik bağlantı değilse, bu özelliği devre dışı bırakabilirsiniz. + +```caddyfile +php_server { + resolve_root_symlink false +} +``` + +Bu, `root` yönergesi [yer tutucular](https://caddyserver.com/docs/conventions#placeholders) içeriyorsa performansı artıracaktır. +Diğer durumlarda kazanç ihmal edilebilir olacaktır. + +## Günlükler + +Günlük kaydı açıkça çok faydalıdır, ancak tanım gereği, +giriş/çıkış işlemleri ve bellek ayırmaları gerektirir, bu da performansı önemli ölçüde azaltır. +[Günlük seviyesini](https://caddyserver.com/docs/caddyfile/options#log) doğru bir şekilde ayarladığınızdan emin olun, +ve yalnızca gerekli olanı günlüğe kaydedin. + +## PHP Performansı + +FrankenPHP resmi PHP yorumlayıcısını kullanır. +Tüm olağan PHP ile ilgili performans optimizasyonları FrankenPHP ile de geçerlidir. + +Özellikle: + +- [OPcache](https://www.php.net/manual/en/book.opcache.php)'in kurulu, etkin ve doğru şekilde yapılandırıldığını kontrol edin +- [Composer otomatik yükleyici optimizasyonlarını](https://getcomposer.org/doc/articles/autoloader-optimization.md) etkinleştirin +- `realpath` önbelleğinin uygulamanızın ihtiyaçları için yeterince büyük olduğundan emin olun +- [ön yüklemeyi](https://www.php.net/manual/en/opcache.preloading.php) kullanın + +Daha fazla ayrıntı için, [Symfony'nin bu konuya ayrılmış dokümantasyon girişini](https://symfony.com/doc/current/performance.html) okuyun +(ipuçlarının çoğu Symfony kullanmasanız bile faydalıdır). + +## İş Parçacığı Havuzunu Bölme + +Uygulamaların, yüksek yük altında güvenilmez olma eğiliminde olan veya sürekli olarak 10 saniyeden fazla yanıt veren bir +API gibi yavaş harici hizmetlerle etkileşime girmesi yaygındır. +Bu gibi durumlarda, özel "yavaş" havuzlara sahip olmak için iş parçacığı havuzunu bölmek faydalı olabilir. +Bu, yavaş uç noktaların tüm sunucu kaynaklarını/iş parçacıklarını tüketmesini önler ve +bağlantı havuzuna benzer şekilde, yavaş uç noktaya giden isteklerin eş zamanlılığını sınırlar. + +```caddyfile +example.com { + php_server { + root /app/public # uygulamanızın kök dizini + worker index.php { + match /slow-endpoint/* # /slow-endpoint/* yoluyla eşleşen tüm istekler bu iş parçacığı havuzu tarafından işlenir + num 1 # /slow-endpoint/* ile eşleşen istekler için minimum 1 iş parçacığı + max_threads 20 # /slow-endpoint/* ile eşleşen istekler için gerektiğinde 20 iş parçacığına kadar izin ver + } + worker index.php { + match * # diğer tüm istekler ayrı ayrı işlenir + num 1 # diğer istekler için minimum 1 iş parçacığı, yavaş uç noktalar asılı kalmaya başlasa bile + max_threads 20 # diğer istekler için gerektiğinde 20 iş parçacığına kadar izin ver + } + } +} +``` + +Genel olarak, çok yavaş uç noktaları, mesaj kuyrukları gibi ilgili mekanizmalar kullanarak eşzamansız olarak ele almak da tavsiye edilir.