You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe. elastic/apm#632 described a problem with attempting to compress spans on a parent that already ended, but the solution - simply not doing the compression at all - seems rather unfortunate. This scenario can be quite common in some node.js apps (which even #2623 (review) mentions), and it means the compression is then far less effective than it could be.
For example, in one of our apps, we make (indirectly, via a third-party package) a high number of pub/sub redis calls at the end of each transaction, and because they are not awaited, they finish only after the transaction ends. That then leads to charts like these:
The repeated calls there have very little value but can't be compressed at the moment.
Describe the solution you'd like
I wonder if some alternative solutions are possible for this case, for example:
Keep buffering the spans even after the parent ends if there are spans with that parent already in progress. Not sure how hard it would be to keep track of in-progress spans.
Keep buffering for a specified time after the parent ends. E.g., if something ends < 1 second after, a setTimeout is used to send it after the configured time. If it ends later, it's sent immediately, like now.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
elastic/apm#632 described a problem with attempting to compress spans on a parent that already ended, but the solution - simply not doing the compression at all - seems rather unfortunate. This scenario can be quite common in some node.js apps (which even #2623 (review) mentions), and it means the compression is then far less effective than it could be.
For example, in one of our apps, we make (indirectly, via a third-party package) a high number of pub/sub redis calls at the end of each transaction, and because they are not awaited, they finish only after the transaction ends. That then leads to charts like these:
The repeated calls there have very little value but can't be compressed at the moment.
Describe the solution you'd like
I wonder if some alternative solutions are possible for this case, for example:
setTimeout
is used to send it after the configured time. If it ends later, it's sent immediately, like now.The text was updated successfully, but these errors were encountered: