Closed barisyild closed 2 weeks ago
Hi @barisyild , IIUC, you want to capture a profile of what is going on at the time that a slow frame occurs, and discard any other transactions? My best guess to filter out transactions using SentryOptions.beforeSend
, but I'm not sure you can tell from the SentryEvent
that hands you whether there is a slow frame in there or not. @philipphofmann could any of those properties be used to dig for that specific info? I don't think we write it into SentryEvent.context
, .extra
, or as a breadcrumb.
I want to measure the performance in the enter frame event, so I need to create transactions,
@barisyild, our transactions, and spans already contain frame statistics. We have slow and frozen frames and we also have frame delay data, for which we still need to add user-facing docs. Do these not provide enough information for you? If not, what are you missing?
I want to measure the performance in the enter frame event, so I need to create transactions,
@barisyild, our transactions, and spans already contain frame statistics. We have slow and frozen frames and we also have frame delay data, for which we still need to add user-facing docs. Do these not provide enough information for you? If not, what are you missing?
It says in the device logs that a slow frame was detected, but I'm not sure if it was sent to sentry.
I'm not running any transactions, could it be because of that?
@barisyild, the SDK only attaches frame information to transactions, yes. So you need a transaction running.
@barisyild, the SDK only attaches frame information to transactions, yes. So you need a transaction running.
If I start and close transaction each frame, won't it send a transaction for each frame?
I wouldn't recommend creating a transaction for every frame. Transactions should represent a user action and should contain more information than just one span. It's also very expensive to create one transaction per frame. If you really want to get exact frame data you could create a transaction and create spans for each frame, but we currently don't expose that information from the SDK.
I wouldn't recommend creating a transaction for every frame. Transactions should represent a user action and should contain more information than just one span. It's also very expensive to create one transaction per frame. If you really want to get exact frame data you could create a transaction and create spans for each frame, but we currently don't expose that information from the SDK.
This way it is not possible to capture functions that are triggered every frame.
Since this is a game, there can be a lot of performance issues even without user interaction.
I want to measure the performance in the enter frame event, so I need to create transactions,
It's not 100% clear to me what you want to achieve.
Let's take a step back. Please describe your use case, @barisyild. From what you wrote, I assume you want to know exactly when slow frames occur at any time when the game runs.
I want to measure the performance in the enter frame event, so I need to create transactions,
It's not 100% clear to me what you want to achieve.
Let's take a step back. Please describe your use case, @barisyild. From what you wrote, I assume you want to know exactly when slow frames occur at any time when the game runs.
Yes, enterFrame events can potentially slow down at any time and do not require interaction.
The only way to correctly see when a slow frame occurred is to use continuous profiling, which is still experimental. The profiles highlight exactly when a slow or frozen frame occurred. Getting the same data with transactions is currently not possible. We don't create transactions with only spans for slow and frozen frames cause they wouldn't be actionable. You could continuously start and finish transactions with some spans, ideally explaining what's currently happening in your app. The SDK adds the frame data automatically to your manually created transactions.
The only way to correctly see when a slow frame occurred is to use continuous profiling, which is still experimental. The profiles highlight exactly when a slow or frozen frame occurred. Getting the same data with transactions is currently not possible. We don't create transactions with only spans for slow and frozen frames cause they wouldn't be actionable. You could continuously start and finish transactions with some spans, ideally explaining what's currently happening in your app. The SDK adds the frame data automatically to your manually created transactions.
This is already active but only reports interaction based slow downs.
@barisyild, what do you mean by this
? Do you mean continuous profiling or manual transactions? And what are interaction based slow downs
?
@barisyild, what do you mean by
this
? Do you mean continuous profiling or manual transactions? And what areinteraction based slow downs
?
Yes, I am talking about continuous profiling.
Those aren't continuous profiles but UI interaction transactions.. You can learn how to setup profiling here: https://docs.sentry.io/platforms/apple/guides/ios/profiling/.
The profile will show UI frames here:
Those aren't continuous profiles but UI interaction transactions.. You can learn how to setup profiling here: https://docs.sentry.io/platforms/apple/guides/ios/profiling/.
The profile will show UI frames here:
I don't quite understand how to enable continuous profiling, is it enough to enable enableAppLaunchProfiling or call startProfiler?
@barisyild, you don't have to do anything to enable continuous profiling. Just call SentrySDK.startProfiler()
and SentrySDK.stopProfile()
: see https://docs.sentry.io/platforms/apple/guides/ios/profiling/#continuous-profiling.
@barisyild, you don't have to do anything to enable continuous profiling. Just call
SentrySDK.startProfiler()
andSentrySDK.stopProfile()
: see https://docs.sentry.io/platforms/apple/guides/ios/profiling/#continuous-profiling.
I think I still need to start a transaction, but I still don't understand, doesn't this mean that all transactions will be sent?
Can I do something like start a transaction and never close it?
No, with continuous profiling, you don't need to start transactions. Continuous profiles are detached from transactions.
No, with continuous profiling, you don't need to start transactions. Continuous profiles are detached from transactions.
I run the startProfiler function immediately after calling startWithConfigureOptions but it doesn't work.
@barisyild, can you set options.debug = true
and share the log output with us, please? That should help us to investigate the problem.
Closing due to inactivity - reply with updated information if this is still relevant.
Problem Statement
I want to measure the performance in the enter frame event, so I need to create transactions, but the server cannot handle 60 transactions per second, even if it receives 1 frame per second, it cannot handle it.
Is there a way to send only the transaction with slow frames?
Solution Brainstorm
No response
Are you willing to submit a PR?
No response