Производительность приложения sinatra на jruby

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, и я хотел убедиться, что это хорошо ведет себя в среде, которая потенциально использует другие модели потоков. Одна итерация в одном потоке выполняется примерно через 0,02 секунды после разогрева jruby.

Так что выше это хорошо, но когда я добавить это Синатра веб-сервер со следующим:

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

Время отклика на запрос к этой конечной точке составляет около .5 секунд - Увеличение числа одновременные запросы, и время отклика растет линейным образом. Я использовал как jetty-rackup, так и trinidad, чтобы попробовать это, используя jruby 1.7 на linux и solaris.

Я попытался оптимизировать экземпляр trinidad безрезультатно (max/min runtimes и т. Д.). Лучшая производительность, которую мы видели, - это запустить сервер в потоковом режиме! режиме, и оба сервера показывают сравнительную производительность в этом режиме.

Может ли кто-нибудь объяснить мне, где время потребляется или как улучшить эту настройку?

Answer 1

Это не похоже, что сервер является ограничивающим фактором. Возможно, это проблема с стойкой или Sinatra, но

на самом деле ничего не дает. Попробуйте использовать инструмент профилирования (VisualVM в порядке, чтобы начать), чтобы проверить, не выделяете ли вы массы объектов, которые вам не нужны, независимо от того, ожидают ли ваши потоки, e.t.c, затем измените или устраните то, что вы считаете узким местом.

Повторяйте это, пока не посчитаете это достаточно быстрым;)