Laravel 11.x Laravel Octane

イントロダクションIntroduction

Laravel Octane（オクタン）は、FrankenPHP、Open Swoole、Swoole、RoadRunnerなどの高性能なアプリケーションサーバを使用し、アプリケーションを提供することで、アプリケーションのパフォーマンスを向上させます。Octaneはアプリケーションを一度起動したら、メモリ内に保持し、そして超音速でリクエストを送り返します。Laravel Octane[https://github.com/laravel/octane] supercharges your application's performance by serving your application using high-powered application servers, including FrankenPHP[https://frankenphp.dev/], Open Swoole[https://openswoole.com/], Swoole[https://github.com/swoole/swoole-src], and RoadRunner[https://roadrunner.dev]. Octane boots your application once, keeps it in memory, and then feeds it requests at supersonic speeds.

インストールInstallation

Octaneは、Composerパッケージマネージャでインストールできます。Octane may be installed via the Composer package manager:

composer require laravel/octane

Octaneをインストールしたら、octane:install Artisanコマンドを実行してください。これにより、オクタンの設定ファイルをアプリケーションへインストールします。After installing Octane, you may execute the octane:install Artisan command, which will install Octane's configuration file into your application:

php artisan octane:install

サーバ要件Server Prerequisites

warning Warning! Laravel Octaneには、PHP8.1以降が必要です。[!WARNING]
Laravel Octane requires PHP 8.1+[https://php.net/releases/].

FrankenPHPFrankenPHP

FrankenPHPはGoで書かれたPHPアプリケーションサーバです。Early hints、Brotli、Zstandard圧縮といった最新のウェブ機能をサポートしています。Octane をインストールし、FrankenPHP をサーバとして選択すると、Octaneが自動的にFrankenPHPのバイナリをダウンロードしてインストールします。FrankenPHP[https://frankenphp.dev] is a PHP application server, written in Go, that supports modern web features like early hints, Brotli, and Zstandard compression. When you install Octane and choose FrankenPHP as your server, Octane will automatically download and install the FrankenPHP binary for you.

Laravel SailでのFrankenPHPの利用FrankenPHP via Laravel Sail

Laravel Sailを使用し、アプリケーションを開発する場合は、以下のコマンドを実行し、OctaneとFrankenPHPをインストールしてください：If you plan to develop your application using Laravel Sail[/docs/{{version}}/sail], you should run the following commands to install Octane and FrankenPHP:

./vendor/bin/sail up

./vendor/bin/sail composer require laravel/octane

次に、octane:install Artisanコマンドを使い、FrankenPHPバイナリをインストールします。Next, you should use the octane:install Artisan command to install the FrankenPHP binary:

./vendor/bin/sail artisan octane:install --server=frankenphp

最後に、アプリケーションのdocker-compose.ymlファイル内のlaravel.testサービス定義へ、SUPERVISOR_PHP_COMMAND環境変数を追加します。この環境変数には、SailがPHP開発サーバの代わりにOctaneを使用してアプリケーションを提供する際に使用するコマンドを格納します。Finally, add a SUPERVISOR_PHP_COMMAND environment variable to the laravel.test service definition in your application's docker-compose.yml file. This environment variable will contain the command that Sail will use to serve your application using Octane instead of the PHP development server:

services:
  laravel.test:
    environment:
      SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=frankenphp --host=0.0.0.0 --admin-port=2019 --port='${APP_PORT:-80}'" # [tl! add]
      XDG_CONFIG_HOME:  /var/www/html/config # [tl! add]
      XDG_DATA_HOME:  /var/www/html/data # [tl! add]

HTTPS、HTTP/2、HTTP/3を有効にするには、代わりに以下の修正をしてください。To enable HTTPS, HTTP/2, and HTTP/3, apply these modifications instead:

services:
  laravel.test:
    ports:
        - '${APP_PORT:-80}:80'
        - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'
        - '443:443' # [tl! add]
        - '443:443/udp' # [tl! add]
    environment:
      SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --host=localhost --port=443 --admin-port=2019 --https" # [tl! add]
      XDG_CONFIG_HOME:  /var/www/html/config # [tl! add]
      XDG_DATA_HOME:  /var/www/html/data # [tl! add]

通常、FrankenPHP Sailアプリケーションは、https://localhostよりアクセスします。https://127.0.0.1を使うには追加の設定が必要であり、推奨していません 。Typically, you should access your FrankenPHP Sail application via https://localhost, as using https://127.0.0.1 requires additional configuration and is discouraged[https://frankenphp.dev/docs/known-issues/#using-https127001-with-docker].

DockerでのFrankenPHPの利用FrankenPHP via Docker

FrankenPHPの公式Dockerイメージを使用すれば、パフォーマンスを向上させ、FrankenPHPの静的インストールには含まれていない拡張機能も使用できます。さらに、FrankenPHPの公式Dockerイメージは、 WindowsのようなFrankenPHPがネイティブにサポートしていないプラットフォームでの実行をサポートしています。FrankenPHPの公式Dockerイメージは、ローカルでの開発にも、本番環境での使用にも適しています。Using FrankenPHP's official Docker images can offer improved performance and the use of additional extensions not included with static installations of FrankenPHP. In addition, the official Docker images provide support for running FrankenPHP on platforms it doesn't natively support, such as Windows. FrankenPHP's official Docker images are suitable for both local development and production usage.

FrankenPHPで動くLaravelアプリケーションをコンテナ化する出発点として、以下のDockerfileを使用してください。You may use the following Dockerfile as a starting point for containerizing your FrankenPHP powered Laravel application:

FROM dunglas/frankenphp

RUN install-php-extensions \
    pcntl
    # ここに他のPHP拡張…

COPY . /app

ENTRYPOINT ["php", "artisan", "octane:frankenphp"]

開発中はアプリケーションを実行するため、以下のDocker Composeファイルを利用してください。Then, during development, you may utilize the following Docker Compose file to run your application:

# compose.yaml
services:
  frankenphp:
    build:
      context: .
    entrypoint: php artisan octane:frankenphp --workers=1 --max-requests=1
    ports:
      - "8000:8000"
    volumes:
      - .:/app

--log-levelオプションをphp artisan octane:startコマンドへ明示的に渡した場合、OctaneはFrankenPHPのネイティブなロガーを使用し、別の設定をしない限り、構造化されたJSONログを生成します。If the --log-level option is explicitly passed to the php artisan octane:start command, Octane will use FrankenPHP's native logger and, unless configured differently, will produce structured JSON logs.

FrankenPHPをDockerで実行するための詳細は、FrankenPHP公式ドキュメントを参照してください。You may consult the official FrankenPHP documentation[https://frankenphp.dev/docs/docker/] for more information on running FrankenPHP with Docker.

RoadRunnerRoadRunner

RoadRunnerは、Goにより構築されたRoadRunnerバイナリで動作します。初めてRoadRunnerベースのオクタンサーバを起動するとき、OctaneはRoadRunnerバイナリをダウンロードしてインストールするよう指示します。RoadRunner[https://roadrunner.dev] is powered by the RoadRunner binary, which is built using Go. The first time you start a RoadRunner based Octane server, Octane will offer to download and install the RoadRunner binary for you.

Laravel SailによるRoadRunnerRoadRunner via Laravel Sail

Laravel Sailを使用してアプリケーションを開発予定の場合は、OctaneとRoadRunnerをインストールする、以下のコマンドを実行する必要があります。If you plan to develop your application using Laravel Sail[/docs/{{version}}/sail], you should run the following commands to install Octane and RoadRunner:

./vendor/bin/sail up

./vendor/bin/sail composer require laravel/octane spiral/roadrunner-cli spiral/roadrunner-http

次に、Sailシェルを起動し、rr実行可能ファイルを使用して、RoadRunnerバイナリのLinuxベースの最新ビルドを取得します。Next, you should start a Sail shell and use the rr executable to retrieve the latest Linux based build of the RoadRunner binary:

./vendor/bin/sail shell

# Sailシェルの中で実行
./vendor/bin/rr get-binary

次に、アプリケーションのdocker-compose.ymlファイル内のlaravel.testサービス定義へ、SUPERVISOR_PHP_COMMAND環境変数を追加します。この環境変数には、SailがPHP開発サーバの代わりにOctaneを使用してアプリケーションを提供する際に使用するコマンドを格納します。Then, add a SUPERVISOR_PHP_COMMAND environment variable to the laravel.test service definition in your application's docker-compose.yml file. This environment variable will contain the command that Sail will use to serve your application using Octane instead of the PHP development server:

services:
  laravel.test:
    environment:
      SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=roadrunner --host=0.0.0.0 --rpc-port=6001 --port='${APP_PORT:-80}'" # [tl! add]

最後に、rrバイナリが実行可能であることを確認し、Sailイメージを構築してください:Finally, ensure the rr binary is executable and build your Sail images:

chmod +x ./rr

./vendor/bin/sail build --no-cache

SwooleSwoole

Swooleアプリケーションサーバを使用してLaravel Octaneアプリケーションを提供する予定の場合は、Swool PHP拡張をインストールする必要があります。通常、これはPECLで行います。If you plan to use the Swoole application server to serve your Laravel Octane application, you must install the Swoole PHP extension. Typically, this can be done via PECL:

pecl install swoole

Open SwooleOpen Swoole

Open Swooleアプリケーションサーバを使用してLaravel Octaneアプリケーションを提供したい場合、Open Swoole PHP拡張をインストールする必要があります。一般的に、これはPECLを介して行えます。If you want to use the Open Swoole application server to serve your Laravel Octane application, you must install the Open Swoole PHP extension. Typically, this can be done via PECL:

pecl install openswoole

Laravel OctaneとOpen Swooleを併用することで、同時並行タスク、tick、intervalなどSwooleが提供する機能と同じものが使えるようになります。Using Laravel Octane with Open Swoole grants the same functionality provided by Swoole, such as concurrent tasks, ticks, and intervals.

Laravel Sailを使用するSwooleSwoole via Laravel Sail

warning Warning! Sailを介してOctaneアプリケーションを動作させる前に、最新バージョンのLaravel Sailであることを確認し、アプリケーションのルートディレクトリ内で./vendor/bin/sail build --no-cacheを実行してください。[!WARNING]
Before serving an Octane application via Sail, ensure you have the latest version of Laravel Sail and execute ./vendor/bin/sail build --no-cache within your application's root directory.

あるいは、Laravelの公式Dockerベース開発環境であるLaravel Sailを使用して、SwooleベースのOctaneアプリケーションを開発することもできます。Laravel SailにはデフォルトでSwooleエクステンションが含まれています。ただし、Sailが使用するdocker-compose.ymlファイルを調整する必要があります。Alternatively, you may develop your Swoole based Octane application using Laravel Sail[/docs/{{version}}/sail], the official Docker based development environment for Laravel. Laravel Sail includes the Swoole extension by default. However, you will still need to adjust the docker-compose.yml file used by Sail.

これを使用するには、アプリケーションのdocker-compose.ymlファイル内のlaravel.testサービス定義へ、SUPERVISOR_PHP_COMMAND環境変数を追加します。この環境変数には、SailがPHP開発サーバの代わりにOctaneを使用してアプリケーションを提供する際に使用するコマンドを格納します。To get started, add a SUPERVISOR_PHP_COMMAND environment variable to the laravel.test service definition in your application's docker-compose.yml file. This environment variable will contain the command that Sail will use to serve your application using Octane instead of the PHP development server:

services:
  laravel.test:
    environment:
      SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=swoole --host=0.0.0.0 --port='${APP_PORT:-80}'" # [tl! add]

最後に、Sailイメージを構築します。Finally, build your Sail images:

./vendor/bin/sail build --no-cache

Swoole設定Swoole Configuration

Swooleは追加設定オプションをサポートしており、必要に応じてoctane設定ファイルへ追加できます。これらのオプションはほとんど変更する必要がないため、デフォルトのコンフィギュレーションファイルには含まれていません。Swoole supports a few additional configuration options that you may add to your octane configuration file if necessary. Because they rarely need to be modified, these options are not included in the default configuration file:

'swoole' => [
    'options' => [
        'log_file' => storage_path('logs/swoole_http.log'),
        'package_max_length' => 10 * 1024 * 1024,
    ],
],

アプリケーションの提供Serving Your Application

Octaneサーバはoctane:start Artisanコマンドで起動できます。このコマンドは、デフォルトでアプリケーションのoctane設定ファイルのserver設定オプションで指定したサーバを利用します。The Octane server can be started via the octane:start Artisan command. By default, this command will utilize the server specified by the server configuration option of your application's octane configuration file:

php artisan octane:start

Octaneはデフォルトで、ポート8000​​のサーバを起動するので、Webブラウザからhttp://localhost:8000で、アプリケーションへアクセスできます。By default, Octane will start the server on port 8000, so you may access your application in a web browser via http://localhost:8000.

HTTPSを使用するアプリケーションの提供Serving Your Application via HTTPS

デフォルトでは、Octaneを介して実行されているアプリケーションは、http://を先頭につけたリンクを生成します。アプリケーションのconfig/octane.php設定ファイル内で使用されているOCTANE_HTTPS環境変数は、HTTPS経由でアプリケーションのサービスを提供する場合、trueと設定します。この設定値がtrueに設定されている場合、OctaneはLaravelに、生成するすべてのリンクにhttps://を先頭に付けるよう指示します。By default, applications running via Octane generate links prefixed with http://. The OCTANE_HTTPS environment variable, used within your application's config/octane.php configuration file, can be set to true when serving your application via HTTPS. When this configuration value is set to true, Octane will instruct Laravel to prefix all generated links with https://:

'https' => env('OCTANE_HTTPS', false),

Nginxを使用するアプリケーションの提供Serving Your Application via Nginx

lightbulb Note: あなた自身のサーバ設定を管理すること、または堅牢なLaravel Octaneアプリケーションを実行するのに必要なさまざまなサービスをすべて設定するのに慣れていない場合は、Laravel Forgeの使用を考慮してください。[!NOTE]
If you aren't quite ready to manage your own server configuration or aren't comfortable configuring all of the various services needed to run a robust Laravel Octane application, check out Laravel Forge[https://forge.laravel.com].

本番環境では，NginxやApacheのような伝統的なWebサーバの背後で、Octaneアプリケーションを提供するべきです。そうすることでWebサーバは，画像やスタイルシートなどの静的資産を提供でき，またSSL証明書のターミネーションを管理できます。In production environments, you should serve your Octane application behind a traditional web server such as Nginx or Apache. Doing so will allow the web server to serve your static assets such as images and stylesheets, as well as manage your SSL certificate termination.

下記のNginx設定例では、Nginxはサイトの静的アセットを提供し、ポート8000​​で実行されるOctanサーバへのプロキシリクエストを提供します。In the Nginx configuration example below, Nginx will serve the site's static assets and proxy requests to the Octane server that is running on port 8000:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    listen [::]:80;
    server_name domain.com;
    server_tokens off;
    root /home/forge/domain.com/public;

    index index.php;

    charset utf-8;

    location /index.php {
        try_files /not_exists @octane;
    }

    location / {
        try_files $uri $uri/ @octane;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/domain.com-error.log error;

    error_page 404 /index.php;

    location @octane {
        set $suffix "";

        if ($uri = /index.php) {
            set $suffix ?$query_string;
        }

        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header Scheme $scheme;
        proxy_set_header SERVER_PORT $server_port;
        proxy_set_header REMOTE_ADDR $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_pass http://127.0.0.1:8000$suffix;
    }
}

ファイル変更の監視Watching for File Changes

Octane Serverが起動するとアプリケーションがメモリにロードされているので、ブラウザを更新してもアプリケーションのファイルの変更は反映されません。たとえば、routes/web.phpファイルに追加されたルート定義は、サーバが再起動されるまで反映されません。利便性を上げるため、アプリケーション内のいずれかのファイルの変更でサーバを自動的に再起動するように、--watchフラグを使用してOctaneへ指示できます。Since your application is loaded in memory once when the Octane server starts, any changes to your application's files will not be reflected when you refresh your browser. For example, route definitions added to your routes/web.php file will not be reflected until the server is restarted. For convenience, you may use the --watch flag to instruct Octane to automatically restart the server on any file changes within your application:

php artisan octane:start --watch

この機能を使用する前に、Nodeがローカル開発環境内にインストールされていることを確認する必要があります。さらに、プロジェクト内にChokidarファイル監視ライブラリをインストールする必要もあります。Before using this feature, you should ensure that Node[https://nodejs.org] is installed within your local development environment. In addition, you should install the Chokidar[https://github.com/paulmillr/chokidar] file-watching library within your project:

npm install --save-dev chokidar

アプリケーションのconfig/octane.php設定ファイル内のwatch設定オプションを使用して、監視対象のディレクトリとファイルを設定できます。You may configure the directories and files that should be watched using the watch configuration option within your application's config/octane.php configuration file.

ワーカ数の指定Specifying the Worker Count

Octaneはデフォルトで、マシンの各CPUコアごとにアプリケーションリクエストワーカを起動します。こうしたワーカは、アプリケーションがHTTPリクエストを受信するサーバとして動作します。octane:startコマンドを呼び出すときの--workersオプションにより、いくつの数のワーカをはじめに起動するか指定できます。By default, Octane will start an application request worker for each CPU core provided by your machine. These workers will then be used to serve incoming HTTP requests as they enter your application. You may manually specify how many workers you would like to start using the --workers option when invoking the octane:start command:

php artisan octane:start --workers=4

Swooleアプリケーションサーバを使用している場合は、「タスクワーカ」の数を指定することもできます。If you are using the Swoole application server, you may also specify how many "task workers"[#concurrent-tasks] you wish to start:

php artisan octane:start --workers=4 --task-workers=6

最大リクエスト数の指定Specifying the Max Request Count

メモリリークを防ぐために、Octaneは500リクエストを処理した時点でワーカを再起動します。この回数を調整するには、--max-requestsオプションを使います。To help prevent stray memory leaks, Octane gracefully restarts any worker once it has handled 500 requests. To adjust this number, you may use the --max-requests option:

php artisan octane:start --max-requests=250

ワーカのリロードReloading the Workers

octane:reloadコマンドを使用して、Octaneサーバのアプリケーションワーカを穏やかに再起動することができます。通常、これはデプロイ後に行われ、新しくデプロイしたコードがメモリへロードされ、後続のリクエストから使用されます。You may gracefully restart the Octane server's application workers using the octane:reload command. Typically, this should be done after deployment so that your newly deployed code is loaded into memory and is used to serve to subsequent requests:

php artisan octane:reload

サーバの停止Stopping the Server

octane:stop Artisanコマンドで、Octaneサーバを停止できます。You may stop the Octane server using the octane:stop Artisan command:

php artisan octane:stop

サーバ状態の確認Checking the Server Status

octane:status Artisanコマンドで、Octaneサーバの現在のステータスを確認できます。You may check the current status of the Octane server using the octane:status Artisan command:

php artisan octane:status

依存注入とOctaneDependency Injection and Octane

Octaneは一度あなたのアプリケーションを起動したら、リクエストを処理しながらメモリに常駐するので、アプリケーション構築中に考慮すべき警告がいくつかあります。たとえば、アプリケーションのサービスプロバイダのregisterとbootメソッドは、リクエストワーカが最初に起動したときにのみ実行されます。後続のリクエストでは、同じアプリケーションインスタンスが再利用されます。Since Octane boots your application once and keeps it in memory while serving requests, there are a few caveats you should consider while building your application. For example, the register and boot methods of your application's service providers will only be executed once when the request worker initially boots. On subsequent requests, the same application instance will be reused.

このことから、アプリケーションサービスのコンテナやリクエストをオブジェクトのコンストラクタへ注入する際には、特に注意が必要になります。これにより後続のリクエストで、そのオブジェクトはコンテナやリクエストの古いバージョンを持つことになります。In light of this, you should take special care when injecting the application service container or request into any object's constructor. By doing so, that object may have a stale version of the container or request on subsequent requests.

Octaneは、リクエスト間でのファーストパーティフレームワークの状態のリセットを自動的に処理します。しかし、Octaneは、アプリケーションが作成する、グローバルな状態をリセットする方法を常に知っているわけでありません。したがって，どのようにしてあなたのアプリケーションをOctaneに適合するように構築するか認識しておく必要があります。以下では，Octaneを使用する際に問題となる可能性のある最も一般的な状況について説明します。Octane will automatically handle resetting any first-party framework state between requests. However, Octane does not always know how to reset the global state created by your application. Therefore, you should be aware of how to build your application in a way that is Octane friendly. Below, we will discuss the most common situations that may cause problems while using Octane.

コンテナ注入Container Injection

一般的に、アプリケーションサービスコンテナやHTTPリクエストインスタンスを他のオブジェクトのコンストラクタへ注入するのは避けるべきです。たとえば、以下の結合では、アプリケーションサービスコンテナ全体がシングルトンとして結合するオブジェクトへ注入されます。In general, you should avoid injecting the application service container or HTTP request instance into the constructors of other objects. For example, the following binding injects the entire application service container into an object that is bound as a singleton:

use App\Service;
use Illuminate\Contracts\Foundation\Application;

/**
 * 全アプリケーションサービスの登録
 */
public function register(): void
{
    $this->app->singleton(Service::class, function (Application $app) {
        return new Service($app);
    });
}

この例では、アプリケーションの起動プロセス中にServiceインスタンスが解決されると、コンテナがサービスに注入され、その後のリクエストでも同じコンテナがServiceインスタンスで保持されます。これは、特定のアプリケーションでは問題にならないかもしれませんが、起動サイクルの後半や後続のリクエストで追加される結合を、コンテナが予期せずに見落としてしまう可能性があります。In this example, if the Service instance is resolved during the application boot process, the container will be injected into the service and that same container will be held by the Service instance on subsequent requests. This may not be a problem for your particular application; however, it can lead to the container unexpectedly missing bindings that were added later in the boot cycle or by a subsequent request.

回避策は、結合をシングルトンとして登録しないか、現在のコンテナインスタンスを常に解決するコンテナリゾルバクロージャをサービスへ注入することです。As a work-around, you could either stop registering the binding as a singleton, or you could inject a container resolver closure into the service that always resolves the current container instance:

use App\Service;
use Illuminate\Container\Container;
use Illuminate\Contracts\Foundation\Application;

$this->app->bind(Service::class, function (Application $app) {
    return new Service($app);
});

$this->app->singleton(Service::class, function () {
    return new Service(fn () => Container::getInstance());
});

グローバルなappヘルパとContainer::getInstance()メソッドは、常にアプリケーションコンテナの最新バージョンを返します。The global app helper and the Container::getInstance() method will always return the latest version of the application container.

リクエストの注入Request Injection

一般的に、アプリケーションサービスコンテナやHTTPリクエストインスタンスを他のオブジェクトのコンストラクタへ注入するのは避けるべきです。たとえば、以下の結合では、シングルトンとして結合したオブジェクトへリクエストインスタンス全体が注入されます。In general, you should avoid injecting the application service container or HTTP request instance into the constructors of other objects. For example, the following binding injects the entire request instance into an object that is bound as a singleton:

use App\Service;
use Illuminate\Contracts\Foundation\Application;

/**
 * 全アプリケーションサービスの登録
 */
public function register(): void
{
    $this->app->singleton(Service::class, function (Application $app) {
        return new Service($app['request']);
    });
}

この例では、アプリケーションのプロセス時にServiceインスタンスが解決されると、HTTPリクエストがサービスへ注入され、以降のリクエストでもServiceインスタンスが同じリクエストを保持することになります。したがって、すべてのヘッダ、入力、およびクエリ文字列のデータは、他のすべてのリクエストデータと同様におかしくなります。In this example, if the Service instance is resolved during the application boot process, the HTTP request will be injected into the service and that same request will be held by the Service instance on subsequent requests. Therefore, all headers, input, and query string data will be incorrect, as well as all other request data.

回避策は、結合をシングルトンとして登録するのをやめるか、現在のリクエストインスタンスを常に解決するリクエストリゾルバクロージャをサービスへ注入することです。あるいは、最も推奨される方法は、単純に、そのオブジェクトが必要とする特定のリクエスト情報を、実行時にオブジェクトのメソッドの１つへ渡すことです。As a work-around, you could either stop registering the binding as a singleton, or you could inject a request resolver closure into the service that always resolves the current request instance. Or, the most recommended approach is simply to pass the specific request information your object needs to one of the object's methods at runtime:

use App\Service;
use Illuminate\Contracts\Foundation\Application;

$this->app->bind(Service::class, function (Application $app) {
    return new Service($app['request']);
});

$this->app->singleton(Service::class, function (Application $app) {
    return new Service(fn () => $app['request']);
});

// もしくは

$service->method($request->input('name'));

グローバルなrequestヘルパは、常にアプリケーションが現在処理しているリクエストを返すので、アプリケーション内で安全に使用できます。The global request helper will always return the request the application is currently handling and is therefore safe to use within your application.

warning Warning! コントローラのメソッドやルートクロージャで、Illuminate\Http\Requestインスタンスをタイプヒントしても構いません。[!WARNING]
It is acceptable to type-hint the Illuminate\Http\Request instance on your controller methods and route closures.

設定リポジトリ注入Configuration Repository Injection

一般的には、設定リポジトリのインスタンスを他のオブジェクトのコンストラクタに注入するのは避けるべきです。たとえば、次の結合は、シングルトンとして結合しているオブジェクトへ設定リポジトリを注入しています。In general, you should avoid injecting the configuration repository instance into the constructors of other objects. For example, the following binding injects the configuration repository into an object that is bound as a singleton:

use App\Service;
use Illuminate\Contracts\Foundation\Application;

/**
 * 全アプリケーションサービスの登録
 */
public function register(): void
{
    $this->app->singleton(Service::class, function (Application $app) {
        return new Service($app->make('config'));
    });
}

この例では、リクエスト間で設定値が変更された場合、そのサービスは元のリポジトリインスタンスに依存しているため、新しい値にアクセスできません。In this example, if the configuration values change between requests, that service will not have access to the new values because it's depending on the original repository instance.

回避策は、結合をシングルトンとして登録するのをやめるか、設定リポジトリのリゾルバクロージャをクラスへ注入することです。As a work-around, you could either stop registering the binding as a singleton, or you could inject a configuration repository resolver closure to the class:

use App\Service;
use Illuminate\Container\Container;
use Illuminate\Contracts\Foundation\Application;

$this->app->bind(Service::class, function (Application $app) {
    return new Service($app->make('config'));
});

$this->app->singleton(Service::class, function () {
    return new Service(fn () => Container::getInstance()->make('config'));
});

グローバルなconfigは、常に最新バージョンの設定リポジトリを返すので、アプリケーション内で安全に使用できます。The global config will always return the latest version of the configuration repository and is therefore safe to use within your application.

メモリリークの管理Managing Memory Leaks

Octaneはリクエストの間中、アプリケーションをメモリ内で常駐させることを忘れないでください。そのため、静的に保持している配列へデータを追加していくと，メモリリークが発生します。例えば，以下のコントローラは，アプリケーションへの各リクエストが静的な$data配列にデータを追加し続けるので，メモリリークが発生します。Remember, Octane keeps your application in memory between requests; therefore, adding data to a statically maintained array will result in a memory leak. For example, the following controller has a memory leak since each request to the application will continue to add data to the static $data array:

use App\Service;
use Illuminate\Http\Request;
use Illuminate\Support\Str;

/**
 * 受信リクエストの処理
 */
public function index(Request $request): array
{
    Service::$data[] = Str::random(10);

    return [
        // ...
    ];
}

アプリケーションを構築する際は、このようなメモリリークを発生させないよう、特に注意する必要があります。ローカル開発時に、アプリケーションのメモリ使用量を監視し、アプリケーションに新たなメモリリークが発生するのを防ぐことを推奨します。While building your application, you should take special care to avoid creating these types of memory leaks. It is recommended that you monitor your application's memory usage during local development to ensure you are not introducing new memory leaks into your application.

現在のタスクConcurrent Tasks

warning Warning! この機能はSwooleが必要です。[!WARNING]
This feature requires Swoole[#swoole].

Swooleを使用している場合，軽量のバックグラウンドタスクを介して，複数操作を同時に実行できます。これには，Octaneのconcurrentlyメソッドを使用します。このメソッドとPHP配列のデストラクションを組み合わせて，各操作の結果を取得できます。When using Swoole, you may execute operations concurrently via light-weight background tasks. You may accomplish this using Octane's concurrently method. You may combine this method with PHP array destructuring to retrieve the results of each operation:

use App\Models\User;
use App\Models\Server;
use Laravel\Octane\Facades\Octane;

[$users, $servers] = Octane::concurrently([
    fn () => User::all(),
    fn () => Server::all(),
]);

Octaneが処理する同時タスクは、Swooleの「タスクワーカー」を利用しており、受信リクエストとは全く別のプロセスで実行されます。同時タスクを処理するために利用できるワーカーの数は、octane:startコマンドの--task-workersディレクティブで決めます。Concurrent tasks processed by Octane utilize Swoole's "task workers", and execute within an entirely different process than the incoming request. The amount of workers available to process concurrent tasks is determined by the --task-workers directive on the octane:start command:

php artisan octane:start --workers=4 --task-workers=6

concurrentlyメソッドを呼び出す場合、Swoole のタスクシステムによる制限のため、1024個以上のタスクを指定してはいけません。When invoking the concurrently method, you should not provide more than 1024 tasks due to limitations imposed by Swoole's task system.

Tickと間隔Ticks and Intervals

warning Warning! この機能はSwooleが必要です。[!WARNING]
This feature requires Swoole[#swoole].

Swooleでは、指定した秒数ごとに実行される"tick"オペレーションが登録できます。"tick"コールバックの登録には、tickメソッドを使用します。tickメソッドの第１引数は、ティッカー(Ticker)の名前を表す文字列を指定します。２番目の引数は、指定した間隔で起動するコールバックを指定します。When using Swoole, you may register "tick" operations that will be executed every specified number of seconds. You may register "tick" callbacks via the tick method. The first argument provided to the tick method should be a string that represents the name of the ticker. The second argument should be a callable that will be invoked at the specified interval.

以下の例では，10秒ごとに呼び出すクロージャを登録しています。通常tickメソッドは、アプリケーションのサービスプロバイダのbootメソッドの中で呼び出します。In this example, we will register a closure to be invoked every 10 seconds. Typically, the tick method should be called within the boot method of one of your application's service providers:

Octane::tick('simple-ticker', fn () => ray('Ticking...'))
        ->seconds(10);

immediateメソッドを使用すると，Octaneサーバが最初に起動したときに，直ちにtickコールバックを起動し，その後はN秒ごとに起動するように指示できます。Using the immediate method, you may instruct Octane to immediately invoke the tick callback when the Octane server initially boots, and every N seconds thereafter:

Octane::tick('simple-ticker', fn () => ray('Ticking...'))
        ->seconds(10)
        ->immediate();

OctaneのキャッシュThe Octane Cache

warning Warning! この機能はSwooleが必要です。[!WARNING]
This feature requires Swoole[#swoole].

Swooleを使用する際には、最大２００万回／秒の読み取り／書き込み速度を実現するOctaneキャッシュドライバが活用できます。したがって、このキャッシュドライバは、キャッシング層からの極端なリード／ライト速度を必要とするアプリケーションに最適な選択肢です。When using Swoole, you may leverage the Octane cache driver, which provides read and write speeds of up to 2 million operations per second. Therefore, this cache driver is an excellent choice for applications that need extreme read / write speeds from their caching layer.

このキャッシュドライバは、Swooleテーブルを利用しています。キャッシュに保存したデータは、サーバ上のすべてのワーカが利用できます。ただし、キャッシュされたデータは、サーバが再起動されるとフラッシュされます。This cache driver is powered by Swoole tables[https://www.swoole.co.uk/docs/modules/swoole-table]. All data stored in the cache is available to all workers on the server. However, the cached data will be flushed when the server is restarted:

Cache::store('octane')->put('framework', 'Laravel', 30);

lightbulb Note: Octaneキャッシュで許可するエントリの最大数は，アプリケーションのoctane設定ファイルで定義できます。[!NOTE]
The maximum number of entries allowed in the Octane cache may be defined in your application's octane configuration file.

キャッシュ間隔Cache Intervals

Laravelのキャッシュシステムが提供する典型的な手法に加え、Octaneキャッシュドライバはインターバルベースのキャッシュを備えています。これらのキャッシュは指定された間隔で自動的にリフレッシュされ、アプリケーションのサービスプロバイダでbootメソッド内に登録する必要があります。例えば、以下のキャッシュは５秒ごとにリフレッシュされます。In addition to the typical methods provided by Laravel's cache system, the Octane cache driver features interval based caches. These caches are automatically refreshed at the specified interval and should be registered within the boot method of one of your application's service providers. For example, the following cache will be refreshed every five seconds:

use Illuminate\Support\Str;

Cache::store('octane')->interval('random', function () {
    return Str::random(10);
}, seconds: 5);

テーブルTables

warning Warning! この機能はSwooleが必要です。[!WARNING]
This feature requires Swoole[#swoole].

Swooleを使用する場合は、任意に独自のSwooleテーブルを定義し、操作できます。Swooleテーブルは、非常に高いパフォーマンスのスループットを提供し、これらのテーブルのデータは、サーバ上のすべてのワーカーからアクセスできます。ただし、サーバを再起動するとテーブル内のデータは失われます。When using Swoole, you may define and interact with your own arbitrary Swoole tables[https://www.swoole.co.uk/docs/modules/swoole-table]. Swoole tables provide extreme performance throughput and the data in these tables can be accessed by all workers on the server. However, the data within them will be lost when the server is restarted.

テーブルは、アプリケーションのoctane設定ファイルのtables設定配列で定義します。テーブルの例として、最大１０００行のテーブルが設定済みです。文字列カラムの最大サイズを設定するには、以下のようにカラムタイプの後にカラムサイズを指定します。Tables should be defined within the tables configuration array of your application's octane configuration file. An example table that allows a maximum of 1000 rows is already configured for you. The maximum size of string columns may be configured by specifying the column size after the column type as seen below:

'tables' => [
    'example:1000' => [
        'name' => 'string:1000',
        'votes' => 'int',
    ],
],

テーブルへアクセスするには、Octane::tableメソッドを使います。To access a table, you may use the Octane::table method:

use Laravel\Octane\Facades\Octane;

Octane::table('example')->set('uuid', [
    'name' => 'Nuno Maduro',
    'votes' => 1000,
]);

return Octane::table('example')->get('uuid');

warning Warning! Swooleのテーブルがサポートする、カラムの型はstring、int、floatです。[!WARNING]
The column types supported by Swoole tables are: string, int, and float.