-
-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Profiling for Ruby #2013
Comments
@sl0thentr0py agree with this, we can't use an external process and we can't use a deterministic (non-sampling) profiler, so |
not that I know of or can find, @st0012 do you know any other ones? |
For Rails/Rack apps, I think we can use Shopify's app_profiler. At the first glance:
However, I don't have much experience profiling in production either. So we'll need to do some testing with it ourselves, but do we have a good application/partner for that? |
copypasta from internal convo for public documentation
given this, how do we want to proceed? Options are:
|
Ah sorry I didn't notice
That looks amazing.
Can you explain more on this?
Given that we don't have experience writing profilers yet, maybe we can go with this first? Even if the result is not accepted by the upstream, at least we'll know more on what we actually want to do and/or can do. |
yes of course and thanks for the feedback!
In a multi-threaded server like puma, there's stuff happening on each thread, and our Here's the thread switcher in the UI from a multi-threaded python profile. How stackprof works (in
For the first MVP, we decided that we will just go with a limited single thread use case, i.e. Stackprof can only run on one thread at a time and will early return if already running. Eventually based on adoption, we might invest time in doing something similar to |
I also fixed some timing issues (but still having some more spurious samples that I'm trying to debug). I'll post some better profiles once everything's done. If you're curious, I also tried out some simple multi-threaded use cases below with this code. require 'sentry-ruby'
require 'debug'
Sentry.init do |config|
config.release = "profiling"
config.debug = true
config.traces_sample_rate = 1.0
end
def t1
10000.times { 2 + 2 }
sleep 0.2
puts('t1')
end
def t2
transaction = Sentry.start_transaction(name: 'profiling')
Sentry.get_current_scope.set_span(transaction)
sleep 0.5
t1
20000.times { 2 * 2 }
puts('t2')
transaction.finish
end
def main
sleep 0.2
20000.times { 2 ** 2 }
puts('main')
end
# transaction = Sentry.start_transaction(name: 'profiling')
# Sentry.get_current_scope.set_span(transaction)
threads = [Thread.new { t1 }, Thread.new { t2 }]
main
threads.each(&:join)
# transaction.finish transaction on main thread transaction on child thread as you can see, we always record call stacks from the thread |
opened issue upstream re: timing issues on puma |
We want to look into extending our Profiling product with support for Ruby.
On other platforms, we used an existing profiler as a starting point or completely relied on external packages.
When a txn starts, a new
profiling_sample_rate
, which works in relation totraces_sample_rate
, determines if this txn should be profiled. Our default sample rate on other platforms is 101Hz.On finish, we convert the raw output to our own profiling format and attach it as a profile envelope item to the transaction.
https://github.com/rbspy/rbspy might be worth looking into, as it's a sampling profiler that also supports outputting a speedscope compatible format, something our own format is derived from.
The text was updated successfully, but these errors were encountered: