問題タブ [capnproto]

を使用して、Python 3 で単純な RPC サーバーを作成していpycapnpます。完了するまでに約 1 秒かかる単一の関数呼び出しがあります。この関数は、キャッシュに格納されたデータも必要とします (現在は を使用して実装されていますlru-dict)。

単一のクライアントではすべてが正常に機能しますが、負荷を増やし始めるとすぐに、リクエストがキューイングを開始します (サーバーで実行されている関数内で測定されたウォール タイムは約 1 秒ですが、クライアントでは簡単に 10 秒以上を取得できます)。

私が知る限り、現在、pycapnp他のイベント ループはサポートされていません。

ThreadPoolExecutorサーバー実装の__init__メソッド (キャッシュも作成される) で を作成してから、RPC メソッドに以下を追加しようとしました。

これが機能している間、メインスレッドは明らかにそれぞれPromiseが満たされるのを待っているようです。これは、クライアントがキューに入れなければならないことを意味します。

似たような状況にある人は、解決策を見つけましたか? 必ずしもを使用する必要はありませんpycapnpが、推奨される Cap'n Proto Python 実装 AFAICT です。

シリアル化してからソケット経由で送信する方が簡単ですか? Cap'n Proto RPC の promise パイプラインやその他の凝った機能は使用しません。

UDS を介して通信するクライアントとサーバーで構成される既存のプロジェクトで Cap'n Proto を使用しようとしています。すべてのクライアント サーバー RPC をやり直すためのリソースはありません (そして、それが受け入れられるとは思えません) が、Cap'n Proto シリアライゼーション メカニズムの恩恵を受けたいと考えていました。残念ながら、それは私には不可能のようです。

最大の問題はサーバー側です。これはシングル スレッドであり (マルチスレッドに深刻な議論がなければ、そのまま残ります)、独自のポーリング ベースのループを使用します。すべてのイベントは部分的に読み取られ、サーバーはイベントが完全に読み取られるのを待つことをブロックできません。これが私が立ち往生している場所です。メッセージをラップする独自のプロトコルとクラスがあり、ファイル記述子からバイトを消費し、イベントが完全に読み取られたときに通知できるため、サーバーはそれを処理できます。Cap'n Proto インターフェイス (シリアル化、非同期シリアル化) のほとんどを分析したと思いますが、変更なしでは同じように使用することはできないようです。

何かを逃したことを本当に願っています。私は？