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

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

この記事では、両方のライブラリのパフォーマンス テストの結果を共有し、コードへの最小限の変更で 3 ～ 5 のパフォーマンス向上を達成できる方法を示したいと思います (総合テストで！).

何をテストしますか？

上記のものをテストします 同期 コネクタは非同期、並列、非同期並列で実行されます。 🙂 また、コネクタ自体のコードにも触れたくありません。 現在、目的を達成するために利用できる拡張機能がいくつかあります。

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

どのようにテストするのでしょうか?

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

データを操作するベンチマーク (挿入、削除、読み取りなど) の場合、ベンチマークを開始する前に、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%* 以内になるまで、反復が繰り返されます。 この後、平均結果が取得されます。 プロセッサーのスロットルを防ぐために、反復の間には XNUMX 秒の一時停止があります。 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)
タランツール/クライアント: 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 コネクタは、標準エンコーダを拡張するか、独自の実装を使用することによって、エンコード プロセスをカスタマイズする機能を提供します。 すぐに使用できるエンコーダーが XNUMX つあり、XNUMX つは以下に基づいています。 msgpack/msgpack-php (公式の MessagePack PECL 拡張)、もう XNUMX つはオンです ライバキット/メッセージパック (純粋な PHP で)。

コネクタを比較する前に、PHP コネクタの MessagePack エンコーダのパフォーマンスを測定し、その後のテストでは最良の結果を示したエンコーダを使用します。

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

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

グラフからわかるように、PECL コネクタ (Tarantool) は、PHP コネクタ (クライアント) と比較して優れたパフォーマンスを示しています。 しかし、後者は遅い言語で実装されていることに加えて、実際にはより多くの作業を実行することを考えると、これは驚くべきことではありません。呼び出しのたびに新しいオブジェクトが作成されます。 リクエスト и レスポンス (選択の場合 - も 基準、Update/Upsert の場合 ― 業務執行統括)、別個のエンティティ 接続, パッカー и ハンドラ オーバーヘッドも追加されます。 明らかに、柔軟性には代償が伴います。 ただし、一般に、PHP インタープリターは優れたパフォーマンスを示します。違いはあるものの、それはわずかであり、PHP 7.4 の JIT はもちろんのこと、PHP 8 でプリロードを使用する場合はさらにパフォーマンスが低下する可能性があります。

次へ移りましょう。 Tarantool 2.0 では SQL のサポートが追加されました。 SQL プロトコルを使用して選択、挿入、更新、および削除の操作を実行して、結果を同等の 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 もありますが、XNUMX つまたは複数のプロセスでベンチマークを実行する場合との違いに気づきませんでした (どこかで失敗した可能性があります)。

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

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

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

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

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

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

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

同期して実行されているコネクタのグラフとの類似性に気づきましたか?

一緒に

最後に、すべての結果を XNUMX つのグラフにまとめて、テストされた拡張機能の全体像を確認しましょう。 まだ行っていない新しいテストを XNUMX つだけチャートに追加しましょう。Parallel* を使用して非同期コルーチンを並列実行してみましょう。 上記の拡張機能を統合するというアイデアはすでに 話し合った しかし、合意に達しなかった場合は、自分で行う必要があります。

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

最終的な結果は次のとおりです。

代わりに、結論の

私の意見では、結果は非常に価値のあるものであることが判明しました。何らかの理由で、これが限界ではないと確信しています。 実際のプロジェクトでこれを自分自身だけで決定する必要があるかどうかは別として、私にとってこれは、最小限の労力で同期 TCP コネクタからどれだけ「絞り出す」ことができるかを評価できる興味深い実験であったということだけを述べておきます。 ベンチマークを改善するためのアイデアがある場合は、プル リクエストを喜んで検討させていただきます。 起動手順と結果を含むすべてのコードは別のドキュメントで公開されます。 リポジトリ.

出所： habr.com