GraphQL Application Server

Commerce GraphQL Application Server は、Adobe Commerceが Commerce GraphQL API リクエストの状態を管理できるようにします。 Swoole 拡張機能に基づいて構築されたGraphQL Application Server は、リクエスト処理を処理するワーカースレッドを使用したプロセスとして動作します。 GraphQL Application Server は、GraphQL API リクエストの間でブートストラップされたアプリケーションの状態を保持することで、リクエスト処理と製品全体のパフォーマンスを向上させます。 API リクエストが大幅に効率的になります。

GraphQL Application Server は、Adobe Commerceでのみ使用できます。 Magento Open Sourceには使用できません。 あなたは必要があります Adobe Commerce サポートの送信 GraphQL Application Server を Pro プロジェクトで有効にするためのチケット。

アーキテクチャ

GraphQL Application Server は、Commerce GraphQL API リクエストの間のステータスを維持し、ブートストラップを行う必要をなくします。 複数のプロセスでアプリケーションのステータスを共有することで、GraphQL リクエストの効率が大幅に向上し、応答時間が最大 30% 短縮します。

共有なし PHP 実行モデルは、要求ごとにフレームワークのブートストラップが必要なため、待ち時間の観点から問題があります。 このブートストラッププロセスには、設定の読み取り、ブートストラッププロセスの設定、サービスクラスオブジェクトの作成など、時間のかかるタスクが含まれます。

リクエスト処理ロジックをアプリケーションレベルのイベントループに移行することは、エンタープライズレベルでリクエスト処理を効率化するという課題に対処するように見えます。 このアプローチにより、リクエスト実行のライフサイクル中にブートストラップを行う必要がなくなります。

メリット

GraphQL Application Server を使用すると、Adobe Commerceは、連続する Commerce GraphQL API リクエストの間にステートを維持できます。 リクエスト間でアプリケーション状態を共有すると、処理オーバーヘッドが最小限に抑えられ、リクエスト処理が最適化されるので、API リクエストの効率が向上します。 その結果、GraphQLのリクエストの応答時間を最大 30% 短縮できます。

必要システム構成

GraphQL Application Server を実行するには、以下が必要です。

クラウドインフラストラクチャでの有効化とデプロイ

この ApplicationServer モジュール （Magento/ApplicationServer/）を指定すると、GraphQL Application Server が有効になります。

Pro プロジェクトの有効化

Pro プロジェクトで Application Server 機能を有効にした後、GraphQL Application Server をデプロイする前に次の手順を実行します。

Pro プロジェクトのデプロイ

イネーブルメント手順を完了したら、変更を Git リポジトリーにプッシュして、GraphQL アプリケーションサーバーをデプロイします。

git push

スタータープロジェクトの有効化

スタータープロジェクトにGraphQL アプリケーションサーバーをデプロイする前に、次の手順を実行します。

スタータープロジェクトのデプロイ

イネーブルメント完了後 手順変更を Git リポジトリーにプッシュして、GraphQL アプリケーションサーバーをデプロイします。

git push

クラウドプロジェクトでのイネーブルメントの検証

これらの検証手順が正常に完了した場合は、GraphQL Application Server が動作しており、 /graphql リクエスト。

オンプレミスプロジェクトの有効化

この ApplicationServer モジュール （Magento/ApplicationServer/）を使用すると、GraphQL API 用のGraphQL Application Server を有効にできます。

GraphQL Application Server をローカルで実行するには、Swoole 拡張機能をインストールし、デプロイメントの Nginx 設定ファイルに小さな変更を加える必要があります。

前提条件

を有効にする前に、次の手順を実行します ApplicationServer モジュール：

Nginx の設定

特定の Commerce デプロイメントによって、Nginx の設定方法が決まります。 一般に、Nginx 設定ファイルは、デフォルトではという名前になっています。 nginx.conf およびは、次のディレクトリのいずれかに配置されます。 /usr/local/nginx/conf, /etc/nginx、または /usr/local/etc/nginx. 参照： 初心者向けガイド nginx の設定の詳細については、を参照してください。

Nginx 設定の例：

location /graphql {
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_pass http://127.0.0.1:9501/graphql;
}

Swoole のインストールと設定

GraphQL Application Server をローカルで実行するには、Swoole 拡張機能（v5.0 以降）をインストールします。 この拡張機能をインストールする方法は複数あります。

次の手順では、OSX ベースのシステムに Swoole extension for PHP 8.2 をインストールする方法について説明します。 これは、Swoole 拡張機能をインストールする方法の 1 つです。

pecl install swoole

インストール時に、Adobe Commerceは以下のサポートを有効にするよう求めます openssl, mysqlnd, sockets, http2、および postgres. Enter yes を除くすべてのオプション postgres.

Swoole のインストールの確認

拡張機能が正常に有効になったことを確認します。

php -m | grep swoole

Swoole のインストールに関するよくあるエラー

Swoole のインストール中に発生するエラーは、通常、 pecl インストール段階。 典型的なエラーとしては、 openssl.h および pcre2.h ファイル。 これらのエラーを解決するには、ローカルシステムにこれらの 2 つのパッケージがインストールされていることを確認します。

openssl version -d

このコマンドは、次のパスを表示します openssl がインストールされました。

pcre2-config --prefix

コマンド出力にファイルが見つからないことが示されている場合は、Homebrew を使用して見つからないパッケージをインストールします。

brew install openssl

brew install pcre2

openssl の問題を解決

に関連した問題を解決するには openssl、実行：

export LDFLAGS="-L/opt/homebrew/etc/openssl@3/lib" export CPPFLAGS="-I/opt/homebrew/etc/openssl@3/include"

ローカルのパスを使用していることを確認します dev 環境。

Openssl 関連の問題の解決の確認

次のコマンドを再度実行すると、openssl 関連の問題が解決されたかどうかを確認できます。

pecl install swoole

pcre2.h の問題を解決

に関連した問題を解決するには pcre2.h、シンボリックリンク pcre2.h インストールした PHP 拡張ディレクトリへのパス。 特定のインストール済みバージョンの PHP pcr2.h 使用するコマンドの特定のバージョンを決定します。

GraphQL Application Server の実行

GraphQL Application Server を起動します。

bin/magento server:run

このコマンドは、9501 で HTTP ポートを開始します。 GraphQL Application Server が起動すると、ポート 9501 はすべてのGraphQL クエリの HTTP プロキシサーバーになります。

デプロイメントでGraphQL Application Server が実行中であることを確認するには：

ps aux | grep php

GraphQL Application Server が実行中であることを確認するその他の方法を次に示します。

GraphQL リクエストが処理中であることを確認します

GraphQL Application Server は、 X-Backend 応答ヘッダー（値：） graphql_server を処理する各リクエストに対して実行します。 リクエストがGraphQL Application Server によって処理されたかどうかを確認するには、この応答ヘッダーを確認します。

拡張機能とカスタマイズの互換性の確認

拡張機能の開発者とマーチャントは、まず、拡張機能とカスタマイズコードがに記載されている技術的なガイドラインに準拠していることを確認する必要があります。 技術ガイドライン.

コード評価時には、次のガイドラインを考慮してください。

GraphQL Application Server の無効化

GraphQL Application Server を無効にする手順は、サーバーがオンプレミスとクラウドのどちらのデプロイメントで実行されているかによって異なります。

GraphQL Application Server （Cloud）を無効にする

GraphQL Application Server を無効にする（オンプレミス）

GraphQL Application Server を無効にするこの方法は、パフォーマンスをすばやくテストまたは比較するのに役立ちます。

GraphQL Application Server が無効になっていることを確認します。

GraphQL リクエストがによって処理されていることを確認するには php-fpm GraphQL Application Server の代わりに、次のコマンドを入力します。 ps aux | grep php.

GraphQL Application Server が無効になった後：

GraphQL Application Server の統合および機能テスト

拡張機能の開発者は、2 つの統合テストを実行して、GraphQL Application Server との拡張機能の互換性を確認できます。 GraphQlStateTest および ResetAfterRequestTest.

GraphQlStateTest

GraphQlStateTest 複数のリクエストで再利用してはいけない共有オブジェクトの状態を検出します。

このテストは、によって生成されるサービスオブジェクトの状態変化を検出するように設計されています。 ObjectManager. このテストでは、同一のGraphQL クエリを 2 回実行し、2 回目のクエリの前後でサービスオブジェクトのステートを比較します。

GraphQlStateTest の失敗と潜在的な修正

実行 GraphQlStateTest 実行による vendor/bin/phpunit -c $(pwd)/dev/tests/integration/phpunit.xml dev/tests/integration/testsuite/Magento/GraphQl/App/GraphQlStateTest.php.

ResetAfterRequestTest

ResetAfterRequestTest は、を実装するすべてのクラスを検索します ResetAfterRequestInterface を実行して、 _resetState() メソッドは、オブジェクトの状態を、で構築された後に保持したのと同じ状態に返します。 ObjectManager.  このテストでは、次のサービス オブジェクトを作成します ObjectManagerその後、オブジェクトを複製し、を呼び出します _resetState()を選択し、両方のオブジェクトを比較します。 このテストでは、オブジェクトのインスタンス化との間でメソッドは呼び出されません。 _resetState()そのため、可変状態のリセットは確認されません。 バグやタイプミスが発生した問題を見つけます _resetState() 元の状態とは異なる状態に設定される場合があります。

ResetAfterRequestTest エラーと修復の可能性

機能テスト

拡張機能の開発者は、GraphQL Application Server のデプロイ中に、GraphQLの WebAPI 機能テストと、GraphQLのカスタム自動または手動の機能テストを実行する必要があります。 これらの機能テストは、開発者が潜在的なエラーや互換性の問題を特定するのに役立ちます。

状態監視モード

機能テスト（または手動テスト）の実行中、アプリケーションサーバーはで実行できます --state-monitor mode 状態が意図せずに再利用されているクラスを見つけるのに役立ちます。 アプリケーションサーバーを通常どおり起動します（を追加する以外） --state-monitor パラメーター。

bin/magento server:run --state-monitor

各リクエストが処理されると、新しいファイルがに追加されます。 tmp ディレクトリ（例：） var/tmp/StateMonitor-thread-output-50-6nmxiK. テストが完了したら、これらのファイルは bin/magento server:state-monitor:aggregate-output コマンド。結合された 2 つのファイルを作成します。1 つは XML さらに 1: JSON.

例：

/var/workspace/var/tmp/StateMonitor-json-2024-04-10T18:50:39Z-hW0ucN.json
/var/workspace/var/tmp/StateMonitor-junit-2024-04-10T18:50:39Z-oreUco.xml

これらのファイルは、XML または JSON の表示に使用する任意のツールを使用して調べることができます。これにより、GraphQlStateTest などのサービスオブジェクトの変更されたプロパティが表示されます。 この --state-monitor モードでは、GraphQlStateTest と同じスキップリストとフィルターリストを使用します。