問題タブ [benchmarking]

最高の軽量 Rails ベンチマーク ツールを知っている人はいますか?

Web サーバーのパフォーマンス統計を取得し、セッションごとに認証とページ ナビゲーションをシミュレートする必要があります。httperf を使用しようとしましたが、アプリケーションで TamperingWithCookie 例外が発生しました。

理想的には、アプリケーションとデータベースを Web サーバーのベンチマークから分離したいと考えていますが、これらを組み合わせた結果に興味があります。

私はかなり前からSSDドライブに興味を持っていました。私はデータベースで多くの作業を行っていますが、SSDドライブの有無にかかわらず実行されるTPC-Hなどのベンチマークを見つけることに非常に興味がありました。

外見はあるように聞こえますが、残念ながら見つかりませんでした。私が答えに最も近いのは、このブログ投稿の最初のコメントでした。

http://dcsblog.burtongroup.com/data_center_strategies/2008/11/intels-enterprise-ssd-performance.html

それを書いた仲間は、読み取り/書き込みワークロードが混在しているとパフォーマンスが不足していると主張しているため、企業のSSDテクノロジーに関してはかなり大きな否定論者のようでした。

これ と これのような他のベンチマークが 絶対にばかげた数を示しています。私はそれらを疑うことはありませんが、最初のリンクのコメント投稿者が言ったことが実際に真実であったかどうか興味があります。

とにかく、SSD上のDBで行われたベンチマークを誰かが見つけることができれば、それは素晴らしいことです。

sqlite の :memory: が遅いのはなぜですか?

インメモリ sqlite とディスク ベースの sqlite を使用することでパフォーマンスが向上するかどうかを調べてみました。基本的に、起動時間とメモリを交換して、アプリケーションの実行中にディスクにヒットしない非常に高速なクエリを取得したいと考えています。

ただし、次のベンチマークでは、速度が 1.5 倍しか向上していません。ここでは、1M 行のランダム データを生成し、同じテーブルのディスク ベースとメモリ ベースの両方のバージョンにロードしています。次に、両方のデータベースでランダム クエリを実行し、サイズが約 300k のセットを返します。メモリ ベースのバージョンの方がかなり高速であると予想していましたが、前述のとおり、1.5 倍の速度向上しか得られません。

他のいくつかのサイズのデータ​​ベースとクエリ セットを試しました。:memory: の利点は、データベース内の行数が増えるにつれて増加するようです。いくつかの仮説を立てましたが、なぜ利点がそれほど小さいのかはわかりません。

• 使用されるテーブルは、:memory: を巨大な勝者にするのに十分な大きさ (行) ではありません
• 結合/テーブルが増えると、:memory: の利点がより明確になります。
• 何らかの方法で以前の結果にアクセスできるように、接続または OS レベルで何らかのキャッシュが行われているため、ベンチマークが破損しています。
• 私が見ていないある種の隠しディスクアクセスが進行中です (まだ lsof を試していませんが、ジャーナリングのために PRAGMA をオフにしました)

ここで何か間違ったことをしていますか？:memory: がほぼ即時のルックアップを生成しない理由について何か考えはありますか? ベンチマークは次のとおりです。

これが結果です。かなり広い範囲のクエリ サイズに対して、ディスクはメモリの約 1.5 倍の時間がかかることに注意してください。

RAM は、ディスクに対してほぼ即時であるべきではありませんか? ここで何がうまくいかないのですか？

編集

ここにいくつかの良い提案があります。

私にとっての主なポイントは、**おそらく :memory: を絶対に高速にする方法はありませんが、ディスクアクセスを比較的遅くする方法があるということです。**

つまり、ベンチマークはメモリの実際のパフォーマンスを適切に測定していますが、ディスクの実際のパフォーマンスは測定していません (たとえば、cache_size プラグマが大きすぎるため、または書き込みを行っていないため)。これらのパラメーターをいじって、機会があれば調査結果を投稿します。

そうは言っても、メモリ内データベースからさらに速度を絞り出すことができると考える人がいる場合 (cache_size と default_cache_size をジャッキアップする以外に)、私はすべて耳を傾けています...

サンプルコードは次のとおりです。

}

これにより、次の出力が得られます。何かキーを押すと続行します 。. .

同じメソッドを初めて実行するのに、連続して呼び出すよりも時間がかかるのはなぜですか?

コマンドラインにあげ-XX:CompileThreshold=1000000てみましたが、違いはありませんでした。

最近、ソフトウェア ベンダーからベンチマーク テストのデータが返ってきましたが、明らかな何かが欠けていると思います。

1 秒あたり 17 件のトランザクション (リクエストが正常に完了したことを意味すると思います) があり、これらのリクエストのうち 1500 件を 5 分間で処理できる場合、1 人のユーザーの応答時間を取得するにはどうすればよいでしょうか? この種のことは、ベンチマークでも可能ですか? Apache の構成設定など、他にも多くのデータがありますが、すべての計算方法がわかりません。

彼らが送信したサーバーのセットアップを考慮して、ユーザーの応答時間を推測する方法を知りたいです。他の同様のベンチマーク テストを確認しましたが、リクエストから応答までの時間を測定するのに問題があります。それを得るためにここで提供する必要がある他のデータは何ですか?

Linux カーネルのスケジューラーにいくつかの簡単な変更を加えました。ここで、これらの変更がシステムの応答時間にどのように影響するかを確認したいと思います。つまり、元のスケジューラと比較して、変更を加えたコンテキスト スイッチにかかる時間を知りたいのです。簡単な方法は、タイム スタンプ カウンターを使用し、次に printk を使用してコンテキスト スイッチにかかった時間を出力することです。明らかに、この場合、多くの情報が出力されます。では、Linux スケジューラの応答時間を測定するための他のより良い方法があるのでしょうか?

ありがとう

私は大規模な科学アプリケーションのベンチマークを行っていましたが、同じ入力でも実行速度が 10% 遅くなることがありました。よく調べた結果、私のクアッド コア CPU (具体的には、2.4 GHz で動作する Intel Q6600) のコア #2 で実行されている場合にのみスローダウンが発生することがわかりました。アプリケーションはシングル スレッドであり、ほとんどの時間を CPU 集中型の行列演算ルーチンに費やしています。

1 つのコアが他のコアよりも遅いことがわかったので、すべての実行でプロセッサ アフィニティを同じコアに設定することで、正確なベンチマーク結果を得ることができます。ただし、1つのコアが遅い理由を知りたいです。

CPU の遅い部分を判断するためにいくつかの簡単なテスト ケースを試しましたが、テスト ケースは遅いコア #2 でも同じ時間で実行されました。複雑なアプリケーションのみがスローダウンを示しました。私が試したテストケースは次のとおりです。

• 浮動小数点の乗算と加算:

  /li>

• 三角関数:

  /li>

• 整数加算:

  /li>

• L2 キャッシュをミスさせようとしている間のメモリ コピー:

  /li>

質問:ある CPU コアが他のコアよりも遅いのはなぜですか?また、CPU のどの部分がその速度低下を引き起こしているのでしょうか?

編集:より多くのテストで、いくつかのHeisenbugの動作が示されました。プロセッサ アフィニティを明示的に設定すると、コア #2 でアプリケーションの速度が低下しません。ただし、プロセッサ アフィニティを明示的に設定せずにコア #2 で実行することを選択した場合、アプリケーションの実行速度は約 10% 遅くなります。私の単純なテスト ケースでは、プロセッサ アフィニティが明示的に設定されているため、同じ速度低下が見られなかった理由がこれで説明できます。そのため、コア #2 に住みたいプロセスがあるように見えますが、プロセッサ アフィニティが設定されていると邪魔になりません。

結論:マルチコア マシン上のシングル スレッド プログラムの正確なベンチマークが必要な場合は、必ずプロセッサ アフィニティを設定してください。