2

非同期サーバー管理について質問があります。私はlibevent2と(私自身の学習経験のために)プレーンなANSI Cを使用しています。apache2ユーティリティのabでストレステストを行います。ほとんど-n 10000-c 400。私のデータベースは、ローカル ネットワーク内の debian コンピューター上の SQL サーバーです。そのため、接続はかなり高速です。valgrind も使用してアプリをプロファイリングします ( --leak-check=full --show-reachable=yes)

私は今、1つの問題を抱えています。SQLデータベースへの同期呼び出しを行うと、すべてが正常に機能します。ただし、すべてメイン スレッドで実行されるため、新しいクライアントがデータを受信するまでに時間がかかります (ストレスが発生している間)。SQLデータベースへの非同期呼び出しを行うと、SQL呼び出しが戻る前にクライアントが切断されない限り、すべてがうまく機能します。SQL呼び出しが戻り、クライアントがすでに切断されているとすぐに、バッファがすでに解放されている、ソケットが閉じられているなどの理由で、無効な読み取りエラーがたくさん発生します。すでにさまざまなことを試しましたが、できませんでした。適切な解決策が得られません。

一般的に、このようなものをどのように扱っているかお聞きしたかっただけです。たとえば、接続されているすべてのクライアントを含む BST を保持し、非同期呼び出しが返されたときにそれを検索しますか? まだそこにある場合は、コールバックを実行します。それ以外の場合は破棄しますか? これにより、パフォーマンスがかなり低下する可能性があると思います。ソケットがまだ開いているかどうかも確認しようとしましたが、ちょっと変でした。 recv(fd, buffer, 1, MSG_PEEK)常にreturned -1(オープンおよびクローズされたノンブロッキング ソケット上で)。

さて、私がすでに行ったことを説明するのはちょっと難しいので、皆さんが答えてくれるのを待ちます:-)

こんにちはマルクス

更新:接続ごとにミューテックスを使用するというクレイジーなアイデアがありました。非同期呼び出しに入ると、それをロックし、戻った後に解放します.. :-)しかし、私はこの方法を信頼していません..正しく聞こえません..誰もそのアプローチを推奨できますか?

更新 2: 私は自分のアイデアを試してみましたが、うまくいきました。それを正しくするのは少しトリッキーでしたが、ロックはそれをしました

4

1 に答える 1

0

接続ごとのロックは正常に機能しますが、いくつかの欠点があります。

  • 収量は、接続ごとに 1 つの未処理の要求です。これにより、アプリケーションが拡張できる範囲が制限されます。

  • 接続数を拡大すると、アプリケーションが作成する必要があるミューテックスの数も問題になる可能性があります。

あなたが言及したように、最善の策は、「接続とクライアント要求管理」を「SQLクエリ管理」から切り離すことです。そのためには、応答と要求を一致させる必要があります。数十万のリクエストに対応できるように規模を拡大すると、ルックアップのコストはわずかになります。これを最適化する方法もあります (たとえば、最初にクライアントを対象とし、次にそのクライアントからの要求を対象とする 2 レベルのルックアップ)。クライアント ルックアップでは、クライアントごとに ID を割り当て、高速検索操作を実装できます。

于 2012-06-28T01:54:55.847 に答える