1

モデルの変更を Chrome クライアントのバックボーン コレクションにストリーミングしている Web アプリがあります。更新の種類と見ているものに応じて、ページの一部をレンダリングする場合とレンダリングしない場合があるいくつかのバックボーン ビューがあります。たとえば、モデルに変更を加えると、コレクションのビューが再レンダリングされ、更新中のモデルの詳細パネル ビューが開いている場合と開いていない場合があります。これらのモデルの変更は、サーバー側のワークフローが非常に冗長で迅速なモデルの変更を伴うため、非常に迅速に発生する可能性があります。

問題は次のとおりです。クライアントにメッセージを送信するときに、Web サーバーのプロセスで多数の errno 32 パイプ破損メッセージが表示されますreadyState。

発生していると思われるonmessageのは、次のメッセージが着信するまでに、コールバックでさまざまなビューのレンダリングが完了していないことです。標準出力でこれらのトレースバックを取得した後も、websocket 接続は引き続き機能し、UI は引き続き更新されます。

モデルの変更をメッセージ キューから読み取って websocketにeventlet.sleep(0.02)送信するループを挿入すると、壊れたパイプ メッセージは消えますが、これは実際の解決策ではなく、厄介なハックのように感じます。

websocket のonmessage機能があまりにも多くの仕事をしようとしていて、次のメッセージが入ったときにまだ忙しいという同様の問題を抱えている人はいますか? 誰にも解決策がありますか？

4

1 に答える 1

0

これを行う最も効率的な方法は、クライアントアプリがサーバーに何を表示しているかを伝えることだと思います。サーバーはこれを追跡し、現在表示されているオブジェクトのみに変更を送信し、関連するクライアントにのみ送信します。

これを行う方法は、アイテムの「Who Watch What」リストを使用することです。アイテムは 2 つの方法で索引付けされます。クライアント ID と、各データ オブジェクト内の isVievedBy チェーンリストから (データと混合するのはきれいに見えませんが、非常に効率的です)。また、各データ オブジェクトの lastupdate タイムスタンプも必要です。

クライアントがビューを変更すると、「これを表示しています。バージョン -timestamp- があります」というメッセージがサーバーに送信されます。サーバーはタイムスタンプをチェックし、必要に応じてオブジェクトを送り返します。また、古い "Who Watch What" (クライアント ID でアクセス) 項目を削除し、新しい項目を作成します。

データ オブジェクトが更新されると、このオブジェクトの isVivedBy チェーンリストをループして、どのクライアントを更新する必要があるかを確認します。これを各クライアントのメッセージ バッファに入れ、それらのバッファを手動でフラッシュします (複数のアイテムを同時に更新する場合、1 つの大きなメッセージが送信されます)。

これは大変な作業ですが、多数のオブジェクトと多数のクライアントが存在する場合でも、アプリケーションは効率的で適切にスケーリングされます。有用なメッセージのみを送信し、メッセージが多すぎる可能性はほとんどありません。

onMessage の問題については、データをキューに保存し、非同期で処理します。

于 2012-09-04T15:12:55.190 に答える