7

バックグラウンド

Wiresharkという有名なツールがあります。私は何年もそれを使用してきました。それは素晴らしいですが、パフォーマンスが問題です。一般的な使用シナリオには、後で分析するデータ サブセットを抽出するためのいくつかのデータ準備手順が含まれます。そのステップがなければ、フィルタリングを行うのに数分かかります (トレースが大きいと、Wireshark はほとんど使用できなくなります)。

ここに画像の説明を入力

実際のアイデアは、データ アグリゲーター/ストレージとして使用される、高速で並列かつ効率的な、より優れたソリューションを作成することです。

要件

実際の要件は、最新のハードウェアによって提供されるすべての電力を使用することです。さまざまな種類の最適化の余地があると言わざるを得ません。上位層でうまくいったことを願っていますが、現在の主な問題はテクノロジです。現在の設計によると、パケット デコーダ (ディセクタ) にはいくつかの種類があります。

  • インタラクティブ デコーダー: デコード ロジックは実行時に簡単に変更できます。このようなアプローチは、プロトコル開発者にとって非常に便利です。デコード速度はそれほど重要ではありませんが、柔軟性と高速な結果がより重要です。
  • 組み込み可能なデコーダー: ライブラリーとして使用できます。このタイプは、優れたパフォーマンスを持ち、利用可能なすべての CPU とコアを使用するのに十分な柔軟性を備えていると想定されています。
  • サービスとしてのデコーダー: クリーンな API を介してアクセスできます。このタイプは、最高のパフォーマンスと効率を提供する必要があります

結果

私の現在の解決策は、JVM ベースのデコーダーです。実際のアイデアは、コードの再利用、移植の排除などですが、それでも効率は良好です。

  • 対話型デコーダー: Groovy に実装
  • 組み込み可能なデコーダー: Java で実装
  • サービスとしてのデコーダー: Tomcat + 最適化 + サーブレットにラップされた組み込み可能なデコーダー (バイナリー入力、XML アウト)

解決すべき問題

  • Groovy は多くのパワーとあらゆるものへの道を提供しますが、この特定のケースでは表現力に恵まれていません
  • ツリー構造へのプロトコルのデコードは行き止まりです -- あまりにも多くのリソースが単純に無駄になります
  • メモリ消費量を制御するのはやや困難です。いくつかの最適化を行いましたが、プロファイリングの結果にまだ満足していません
  • さまざまな付加機能を備えた Tomcat では、依然として多くのオーバーヘッドが発生します (主に接続処理)。

どこでも JVM を正しく使用していますか? 最初の目標を達成するための他の優れたエレガントな方法はありますか?

プロトコル、結果の形式などは固定されていません。

4

3 に答える 3

7

私はいくつかの可能な改善を見つけました：

インタラクティブデコーダー

AST Transformationsを使用して Groovy 構文を拡張することにより、Groovy の表現力を大幅に向上させることができます 。そのため、デコーダーのオーサリングを簡素化して、優れたパフォーマンスを提供することができます。AST (Abstract Syntax Tree の略) はコンパイル時の手法です。

Groovy コンパイラーが Groovy スクリプトとクラスをコンパイルすると、プロセスのある時点で、ソース コードは具象構文ツリーの形式でメモリ内に表現され、次に抽象構文ツリーに変換されます。AST 変換の目的は、開発者がコンパイル プロセスにフックして、JVM によって実行されるバイトコードに変換される前に AST を変更できるようにすることです。

プロトコル構造を定義/記述するために、さらに別の言語を導入する車輪を再発明したくありません ( ASN.1があれば十分です)。アイデアは、高速なプロトタイピング技術を提供するために、デコーダの開発を簡素化することです。基本的に、ある種の DSL が導入されます。

参考文献

組み込み可能なデコーダ

Java では、追加のオーバーヘッドが発生する可能性があります。この問題に対処するためのライブラリがいくつかあります。

ここに画像の説明を入力

率直に言って、このレイヤーには Java 以外のオプションはありません。

サービスとしてのデコーダー

このレイヤーには Java は必要ありません。最後に、良い選択肢がありますが、価格はかなり高いです。GWanは本当によく見えます。

ここに画像の説明を入力

追加の移植が必要になりますが、それだけの価値があります。

于 2012-12-03T13:52:33.810 に答える
3

この問題は、メモリ コピーの数がパフォーマンスを支配するという、多くの高パフォーマンス I/O 実装の問題と同じ特徴を共有しているようです。非同期 I/O のスキャッター/ギャザー インターフェイス パターンは、この原則に従います。スキャッター ギャザーでは、メモリ ブロックがその場で操作されます。プロトコル デコーダーがバイト ストリームではなくブロック ストリームを入力として受け取る限り、バイト ストリームの抽象化を維持するためにメモリを移動するパフォーマンスのオーバーヘッドを大幅に削減できます。バイト ストリームは、エンジニアリング時間を節約するための非常に優れた抽象化ですが、高性能 I/O にはあまり適していません。

関連する問題では、基本的なタイプという理由だけで JVM に注意しStringます。JVM での の実装方法に精通しているとは言えませんがString、メモリ コピーを行わずにブロック リストから文字列を作成する方法はないと思います。一方、可能であり、JVMStringと互換性を持って相互運用できるネイティブの種類の文字列は、違いを分割する方法になる可能性があります。

関連すると思われるこの問題のもう 1 つの側面は、形式言語の問題です。メモリのブロックをコピーしないという精神から、同じメモリ ブロックを何度もスキャンすることも望ましくありません。実行時に変更を加えたいので、プリコンパイルされたステート マシンを使用するのではなく、降下の各レベルで適切なプロトコル インタープリターにディスパッチできる再帰降下パーサーを使用する必要があることを意味します。外側のレイヤーが内側のレイヤーのタイプを指定していない場合、複雑な問題が発生します。内部コンテンツの長ささえ取得できない場合、これらの複雑さはさらに悪化します。それでも、1 つのブロックが何回スキャンされるかを理解することに注意を払う価値はあります。

于 2012-12-03T02:39:07.620 に答える
1

ネットワーク トラフィックが増加しているため (一部の分析)、1 秒あたりにより多くのデータを処理する必要があります。

これを達成する唯一の方法は、より多くの CPU パワーを使用することですが、CPU 周波数は安定しています。コアの数だけが増えています。利用可能なコアをより効率的に使用し、より適切にスケーリングすることが唯一の方法のようです。

ここに画像の説明を入力

于 2014-01-24T12:24:44.483 に答える