Async、Swoole、Parallel を使用して Tarantool の PHP コネクタを高速化する

現在、PHPエコシステムにはTarantoolサーバーと連携するためのコネクタが2つあります。これは公式のPECL拡張です。 tarantool/tarantool-phpC言語で書かれており、 tarantool-php/クライアントPHP で書かれています。私は後者の著者です。

この記事では、両方のライブラリのパフォーマンステストの結果を共有し、コードに最小限の変更を加えるだけで3〜5倍のパフォーマンス向上を実現できることを示したいと思います（合成テストで！).

何をテストするのでしょうか?

上記の内容をテストします 同期 非同期、並列、非同期並列で実行されるコネクタ。 🙂 また、コネクタ自体のコードにも触れたくありません。現在、これを実現するのに役立つ拡張機能がいくつかあります。

• スウール ― PHP 用の高性能な非同期フレームワーク。 AlibabaやBaiduなどのインターネット大手で使用されています。バージョン4.1.0以降、マジックメソッドが登場しました SwooleRuntime::enableCoroutine()これにより、「1 行のコードで PHP の同期ネットワーク ライブラリを非同期のものに変換」できるようになります。
• Async は、最近まで、PHP での非同期作業のための非常に有望な拡張機能でした。なぜ最近まで？残念ながら、私には分からない何らかの理由で、作者はリポジトリを削除してしまい、プロジェクトの将来は不透明です。使わなければならない 1 フォークから。 Swoole と同様に、この拡張機能を使用すると、TCP および TLS ストリームの標準実装を非同期バージョンに置き換えることで、非同期動作を簡単にオンにすることができます。これはオプション「非同期TCP = 1"
• 並列シミュレーションの設定 ― phpdbg、apcu、pthreads、pcov、uopz などのライブラリの作者として有名な Joe Watkins による比較的新しい拡張機能です。この拡張機能は、PHP でマルチスレッド用の API を提供し、pthreads の代替として位置付けられています。このライブラリの大きな制限は、PHP の ZTS (Zend Thread Safe) バージョンでのみ動作することです。

どうやってテストするのでしょうか?

先行書き込みログを無効にしたTarantoolのインスタンスを起動してみましょう（wal_mode = なし) とネットワークバッファの増加 (先読み = 1 * 1024 * 1024）。最初のオプションはディスクでの作業を除外し、2 番目のオプションはオペレーティング システム バッファーからより多くの要求を読み取ることを可能にし、それによってシステム コールの数を最小限に抑えます。

データを操作するベンチマーク (挿入、削除、読み取りなど) の場合、ベンチマークの開始前に、memtx スペースが (再) 作成され、その中で、順序付けられた整数値 (シーケンス) のジェネレーターによってプライマリ インデックス値が作成されます。
スペースの DDL は次のようになります。

space = box.schema.space.create(config.space_name, {id = config.space_id, temporary = true})
space:create_index('primary', {type = 'tree', parts = {1, 'unsigned'}, sequence = true})
space:format({{name = 'id', type = 'unsigned'}, {name = 'name', type = 'string', is_nullable = false}})

必要であれば、ベンチマークを実行する前に、次の形式の10,000組で空間を埋める。

{id, "tuplе_<id>"}

タプルへのアクセスはランダムなキー値によって提供されます。

ベンチマーク自体は、サーバーへの単一のリクエストが 10,000 回 (回転) 実行され、それが反復的に実行されるものです。 5 回の反復間のすべての時間偏差が 3%* の許容誤差内になるまで、反復が繰り返されます。この後、平均結果が算出されます。プロセッサのスロットルを防ぐために、反復の間に 1 秒間の一時停止があります。 Lua のガベージ コレクターは各反復の前に無効にされ、完了後に強制的に実行されます。 PHP プロセスは、ベンチマークに必要な拡張機能のみを使用して開始され、出力バッファリングが有効にされ、ガベージ コレクターは無効にされます。

* 回転数、反復回数、エラーしきい値はベンチマーク設定で変更できます。

テスト環境

以下に掲載した結果は、MacBookPro (2015)、オペレーティング システム - Fedora 30 (カーネル バージョン 5.3.8-200.fc30.x86_64) で作成されました。 TarantoolはDockerでパラメータ「--network host".

パッケージバージョン:

Tarantool: 2.3.0-115-g5ba5ed37e
Docker: 19.03.3、ビルド a872fc2f86
PHP: 7.3.11 (cli) (ビルド: 22年2019月08日 11:04:XNUMX)
tarantool/クライアント: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ 7.3 用パッチ)*
ext-msgpack: 2.0.3
外部非同期: 0.3.0-8c1da46
拡張スウール: 4.4.12
拡張パラレル: 1.1.3

* 残念ながら、公式コネクタは PHP バージョン 7.2 以降では動作しません。 PHP 7.3で拡張機能をコンパイルして実行するには、 パッチ.

結果

同期モード

Tarantoolプロトコルはバイナリ形式を使用する メッセージパック メッセージのシリアル化用。 PECL コネクタでは、シリアル化はライブラリの奥深くに隠されており、ユーザーランド コードからのエンコード プロセスに影響を与えることはできません。 できない。一方、純粋な PHP コネクタは、標準エンコーダを拡張するか、独自の実装を使用することによって、エンコード プロセスをカスタマイズする機能を提供します。すぐに使用できるエンコーダは2つあり、1つは msgpack/msgpack-php （公式MessagePack PECL拡張）、もう一つは rybakit/msgpack (純粋な PHP で)。

コネクタを比較する前に、PHP コネクタの MessagePack エンコーダのパフォーマンスを測定し、さらなるテストで最高の結果を示すものを使用しましょう。

PHP バージョン (Pure) は速度の点では PECL 拡張機能より劣りますが、実際のプロジェクトではやはり使用することをお勧めします。 rybakit/msgpack公式のMessagePack拡張機能では、フォーマット仕様が部分的にしか実装されていないため（例えば、カスタムデータ型はサポートされておらず、これがないとTarantool 2.3で導入された新しいデータ型であるDecimalを使用できません）、他の多くの проблем (PHP 7.4 との互換性の問題を含む)。まあ、全体的に見ると、このプロジェクトは放棄されたように見えます。

それでは、同期モードでコネクタのパフォーマンスを測定してみましょう。

グラフからわかるように、PECL コネクタ (Tarantool) は、PHP コネクタ (クライアント) と比較して優れたパフォーマンスを示しています。しかし、後者は、より遅い言語で実装されていることに加えて、本質的にはより多くの作業（呼び出しごとに新しいオブジェクトが作成される）を行うことを考えると、これは驚くべきことではありません。 リクエスト и 世界の動き （セレクトの場合も 基準、Update/Upsertの場合 ― 業務執行統括）、別個のエンティティ 接続, パッカー и ハンドラ オーバーヘッドも追加されます。当然ですが、柔軟性には代償が伴います。ただし、全体的には、PHP インタープリターは良好なパフォーマンスを示しています。違いはあるものの、それは重要ではなく、PHP 7.4 のプリロードを使用するとさらに小さくなる可能性があり、PHP 8 の JIT は言うまでもありません。

次に進みましょう。 Tarantool 2.0 は SQL をサポートするようになりました。 SQL プロトコルを使用して、Select、Insert、Update、Delete 操作を実行し、その結果を noSQL (バイナリ) の同等の結果と比較してみましょう。

SQL の結果はあまり印象的ではありません (同期モードはまだテスト中であることに注意してください)。しかし、私はこれについて事前に怒るつもりはありません。SQLサポートはまだ活発に開発中です（比較的最近、例えば、サポートが追加されました）。 プリペアドステートメント）そして、リストから判断すると 問題今後、SQL エンジンではさまざまな最適化が行われる予定です。

非同期

さて、Async 拡張機能が上記の結果を改善するのにどのように役立つかを見てみましょう。非同期プログラムを作成するために、拡張機能はコルーチンに基づく API を提供しており、これを使用します。経験的に、私たちの環境に最適なコルーチンの数は 25 であることがわかりました。

10,000 回の演算を 25 個のコルーチンに分散させて、次の結果を見てみましょう。

3秒あたりの操作数はXNUMX倍以上に増加しました。 tarantool-php/クライアント!

残念なことに、PECL コネクタは ext-async で起動できませんでした。

SQLについてはどうですか?

ご覧のとおり、非同期モードではバイナリ プロトコルと SQL の差は誤差範囲内になりました。

スウール

今度は Swoole の場合に、コルーチンの最適な数をもう一度調べてみましょう。

25 で止めましょう。Async 拡張機能と同じトリックを繰り返して、10,000 の操作を 25 個のコルーチンに分散しましょう。さらに、すべての作業を 2 つのプロセスに分割する別のテストを追加します (つまり、各プロセスは 5,000 のコルーチンで 25 の操作を実行します)。プロセスは以下を使用して作成されます スウールプロセス.

結果：

Swole は、2 つのプロセスで実行する場合、Async と比較してわずかに低い結果を示しますが、2 つのプロセスでは状況は劇的に変化します (2 という数字は偶然に選択されたわけではなく、私のマシンでは XNUMX つのプロセスが最良の結果を示しました)。

ちなみに、Async 拡張機能にはプロセスを操作するための API もありますが、ベンチマークを 1 つのプロセスで実行した場合と複数のプロセスで実行した場合の違いはわかりませんでした (どこかで失敗した可能性があります)。

SQL とバイナリ プロトコル:

Async の場合と同様に、非同期モードではバイナリ操作と SQL 操作の違いはなくなります。

並列シミュレーションの設定

Parallel 拡張機能はコルーチンではなくスレッドに関するものなので、並列スレッドの最適な数を測定してみましょう。

私のマシンでは 16 です。 16 個の並列スレッドでコネクタ ベンチマークを実行してみましょう。

ご覧のとおり、結果は非同期拡張機能 (2 つのプロセスで実行されている Swoole を除く) よりもさらに優れています。 PECL コネクタの場合、Update 操作と Upsert 操作は空であることに注意してください。これは、これらの操作がエラーでクラッシュしたためです。原因が ext-parallel、ext-tarantool、またはその両方であるかどうかはわかりません。

次に、SQL パフォーマンスを比較してみましょう。

同期的に起動されたコネクタのグラフとの類似性に気づきましたか?

みんなで

最後に、テストした拡張機能の全体像を確認するために、すべての結果を 1 つのグラフにまとめてみましょう。まだ実行していない新しいテストを 1 つだけグラフに追加しましょう。Parallel* を使用して、非同期コルーチンを並列に実行してみましょう。上記の拡張機能を統合するというアイデアはすでに 話し合った 著者らは合意に達しなかったため、私たち自身でそれを行わなければなりません。

* Parallel で Swoole コルーチンを実行できませんでした。これらの拡張機能は互換性がないようです。

最終結果は以下のとおりです。

代わりに、結論の

私の意見では、結果はかなり良好で、何らかの理由でこれが限界ではないと確信しています。実際のプロジェクトでこれが必要かどうかは完全にあなた次第ですが、私にとっては興味深い実験であり、最小限の労力で同期 TCP コネクタからどれだけのものを「絞り出す」ことができるかを評価できたとだけ言っておきます。ベンチマークを改善する方法について何かアイデアがあれば、プル リクエストを検討させていただきます。実行手順と結果を含むコード全体は別の リポジトリ.

出所： habr.com