Question

我有一个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本机线程通过java.concurrent.FixedThreadPool（500））/ ExecutorService，我想确保这在一个环境中表现得很好可能使用其他线程模型。一旦jruby已经预热，单个线程中的单次迭代将在大约0.02秒内运行。

所以上面的内容很好，但是当我将它添加到sinatra Web服务器时，使用以下内容：

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

对此端点的请求的响应时间约为5秒 - 增加并发请求数，响应时间以线性方式上升。我已经使用了jetty-rackup和trinidad来尝试这个，在linux和solaris上使用jruby 1.7。

我试图优化trinidad实例无效（最大/最小运行时间等）。我们看到的最佳性能是在线程安全中运行任一服务器！模式，两个服务器在此模式下显示比较性能。

任何人都可以向我解释消耗时间或者如何改善此设置吗？

Answer 1

听起来不像服务器是限制因素。也许这是机架或Sinatra的问题，但

# ... my stuff here

并没有给予太多的帮助。尝试使用分析工具（VisualVM可以开始）来检查你是否分配了大量不需要的对象，是否所有线程都在等待，然后改变或消除你认为的瓶颈。

重复此操作，直到您认为它足够快;）

sinatra app在jruby上的表现

1 个答案: