イントロダクションIntroduction
Laravel Octane(オクタン)は、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 Open Swoole[https://swoole.co.uk], 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
PHP8.0以上が必要です。Warning
Warning! Laravel Octaneは、
Laravel Octane requires PHP 8.0+[https://php.net/releases/].
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
次に、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
RoadRunnerのバイナリをインストールしたら、Sailシェルセッションを終了してください。アプリケーションを実行し続けるためにSailにより使用される、supervisor.conf
ファイルを調整する必要があります。手始めに、sail:publish
Artisanコマンドを実行してください。After installing the RoadRunner binary, you may exit your Sail shell session. You will now need to adjust the supervisor.conf
file used by Sail to keep your application running. To get started, execute the sail:publish
Artisan command:
./vendor/bin/sail artisan sail:publish
次に、アプリケーションのdocker/supervisord.conf
ファイルのcommand
ディレクティブを更新し、SailがPHP開発サーバの代わりにオクタンを使ってアプリケーションを動かすようにします。Next, update the command
directive of your application's docker/supervisord.conf
file so that Sail serves your application using Octane instead of the PHP development server:
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=80
最後に、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
Laravel SailによるSwooleSwoole Via Laravel Sail
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が使用する、supervisor.conf
ファイルを調整する必要があります。手始めに、sail:publish
Artisanコマンドを実行してください。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 supervisor.conf
file used by Sail to keep your application running. To get started, execute the sail:publish
Artisan command:
./vendor/bin/sail artisan sail:publish
次に、アプリケーションのdocker/supervisord.conf
ファイルのcommand
ディレクティブを更新し、SailがPHP開発サーバの代わりにオクタンを使ってアプリケーションを動かすようにします。Next, update the command
directive of your application's docker/supervisord.conf
file so that Sail serves your application using Octane instead of the PHP development server:
command=/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=swoole --host=0.0.0.0 --port=80
最後に、Sailイメージを構築します。Finally, build your Sail images:
./vendor/bin/sail build --no-cache
Swoole ConfigurationSwoole 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
Laravel Forgeの使用を考慮してください。Note
Note:あなた自身のサーバ設定を管理すること、または堅牢なLaravel Octaneアプリケーションを実行するのに必要なさまざまなサービスをすべて設定するのに慣れていない場合は、
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 a 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 & 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;
/**
* 全アプリケーションサービスの登録
*
* @return void
*/
public function register()
{
$this->app->singleton(Service::class, function ($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;
$this->app->bind(Service::class, function ($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;
/**
* 全アプリケーションサービスの登録
*
* @return void
*/
public function register()
{
$this->app->singleton(Service::class, function ($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.
回避策は、結合をシングルトンとして登録するのをやめるか、現在のリクエストインスタンスを常に解決するリクエストリゾルバクロージャをサービスへ注入することです。あるいは、最も推奨される方法は、単純に、そのオブジェクトが必要とする特定のリクエスト情報を、実行時にオブジェクトのメソッドの1つへ渡すことです。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;
$this->app->bind(Service::class, function ($app) {
return new Service($app['request']);
});
$this->app->singleton(Service::class, function ($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! コントローラのメソッドやルートクロージャで、
Illuminate\Http\Request
インスタンスをタイプヒントしても構いません。Warning
It is acceptable to type-hint theIlluminate\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;
/**
* 全アプリケーションサービスの登録
*
* @return void
*/
public function register()
{
$this->app->singleton(Service::class, function ($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;
$this->app->bind(Service::class, function ($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;
/**
* 受信リクエストの処理
*
* @param \Illuminate\Http\Request $request
* @return void
*/
public function index(Request $request)
{
Service::$data[] = Str::random(10);
// ...
}
アプリケーションを構築する際は、このようなメモリリークを発生させないよう、特に注意する必要があります。ローカル開発時に、アプリケーションのメモリ使用量を監視し、アプリケーションに新たなメモリリークが発生するのを防ぐことを推奨します。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
Swooleが必要です。Warning
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\User;
use App\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 & Intervals
Swooleが必要です。Warning
Warning! この機能は
This feature requires Swoole[#swoole].
Swooleでは、指定した秒数ごとに実行される"tick"オペレーションが登録できます。"tick"コールバックの登録には、tick
メソッドを使用します。tick
メソッドの第1引数は、ティッカー(Ticker)の名前を表す文字列を指定します。2番目の引数は、指定した間隔で起動するコールバックを指定します。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
Swooleが必要です。Warning
Warning! この機能は
This feature requires Swoole[#swoole].
Swooleを使用する際には、最大200万回/秒の読み取り/書き込み速度を実現する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);
Note:Octaneキャッシュで許可するエントリの最大数は,アプリケーションの
octane
設定ファイルで定義できます。Note
The maximum number of entries allowed in the Octane cache may be defined in your application'soctane
configuration file.
キャッシュ間隔Cache Intervals
Laravelのキャッシュシステムが提供する典型的な手法に加え、Octaneキャッシュドライバはインターバルベースのキャッシュを備えています。これらのキャッシュは指定された間隔で自動的にリフレッシュされ、アプリケーションのサービスプロバイダでboot
メソッド内に登録する必要があります。例えば、以下のキャッシュは5秒ごとにリフレッシュされます。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
Swooleが必要です。Warning
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
設定配列で定義します。テーブルの例として、最大1000行のテーブルが設定済みです。文字列カラムの最大サイズを設定するには、以下のようにカラムタイプの後にカラムサイズを指定します。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! Swooleのテーブルがサポートする、カラムの型は
string
、int
、float
です。Warning
The column types supported by Swoole tables are:string
,int
, andfloat
.