2

私はsinatraアプリを持っていますが、これは私が望むよりもかなり遅いパフォーマンスです。私の最初の疑いは、ボトルネックとなっているのは自分のコードであるということです。そこで、スタンドアロンのベンチマークスクリプトにそれを抽出しました。

THREADS = 100
ITERATIONS = 1

def make_calls
  ITERATIONS.times do
 # ... my stuff here
 end
end

1.upto(THREADS) do |n|
  Benchmark.bm do |bm|
    threads = []
    n.times do
      threads << Thread.new { make_calls }
    end
    bm.report("#{n} threads:") { threads.each { |t| t.value } }
  end
end

make_callsが自分のコードを呼び出す場所。100スレッドに達するまでに、すべてのスレッドでのmake_callsの累積時間は0.6秒であり、これは私の目的には十分な速さです。上記のスレッドでmake_callsメソッドをラップしている理由は、自分のコードがスレッド（java.concurrent.FixedThreadPool（500）を介したJavaネイティブスレッド）/ ExecutorServiceを使用しており、これが次のような環境で正常に動作することを確認したかったためです。他のスレッドモデルを使用する可能性があります。jrubyがウォームアップすると、1つのスレッドでの1回の反復は約0.02秒で実行されます。

したがって、上記は適切ですが、これをsinatraWebサーバーに次のように追加すると次のようになります。

require 'sinatra'
get '/' do
  # ... my stuff here
end

このエンドポイントへのリクエストの応答時間は約0.5秒です-同時リクエストの数を増やすと、応答時間は直線的に増加します。Linuxとsolarisの両方でjruby1.7を使用して、jetty-rackupとtrinidadの両方を使用してこれを試しました。

トリニダードインスタンスを無駄に最適化しようとしました（最大/最小ランタイムなど）。私たちが見た中で最高のパフォーマンスは、いずれかのサーバーをスレッドセーフで実行することです。モードであり、両方のサーバーがこのモードで比較パフォーマンスを示します。

誰かが私に時間を費やしている場所やこの設定を改善する方法を説明できますか？

4

1 に答える 1

0

サーバーが制限要因であるようには聞こえません。ラックかシナトラの問題かもしれませんが、

# ... my stuff here

実際にはあまり譲りません。プロファイリング ツール ( VisualVMから始めても問題ありません) を使用して、必要のない大量のオブジェクトを割り当てているかどうか、すべてのスレッドが待機しているかどうかなどを確認してから、ボトルネックと思われるものを変更または排除してください。

十分速いと思うまでこれを繰り返します ;)

于 2013-05-20T13:46:13.650 に答える