Skip to content
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

[1.x] Add average metrics #284

Closed
wants to merge 5 commits into from
Closed

Conversation

aryehraber
Copy link

Hi again!

It was awesome to hear from @timacdonald that you were open to adding averages to the time-related metrics (#281).

I've gone ahead and implemented it for "Slow Jobs", and would love to get your feedback before I continue with the others — just to make sure I'm doing it in the way you would like.

Thanks!

Copy link

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

@jessarcher
Copy link
Member

The only thing to note here is that the average will only be from when the job was over the threshold (e.g. 1,000ms). I'm not sure whether or not this is what people would want/expect.

If we wanted to show the average from every time the job runs, we'd need to capture a lot more data.

What are your thoughts?

@aryehraber
Copy link
Author

@jessarcher That is such a good point... 🤦‍♂️ Completely didn't consider the threshold limiting the data. I would definitely expect the average to be the "real" average and not just from the metrics over the threshold.

I can see how the Recorders would need to capture a lot more data than they currently do for this to work. Perhaps we can make this metric configurable inside each Recorder's config? The config option could then be used to check whether it should capture the average or to ignore it. Additionally, we could then conditionally show/hide the "Average" column to the Livewire component based on the config.

I'll continue working on this idea using the single "Slow Jobs" recorder to see if we like it or not.

@abaldwinls
Copy link

@jessarcher first, I love Pulse, thanks so much for all the work to make this happen!

@aryehraber I really like the idea of having the average, and also wouldn't have initially thought of the avg being "off" and only for slow jobs. For me, I wouldn't mind this being an average of only the slow jobs, since that's what is being tracked. Maybe its just a clearly defined option within the Recorders config for slow_( job | request )_average? With this, if people really wanted to see stats for all jobs/requests, they could make the slow threshold 0. (Not a perfect solution, but it'd work for my needs).

Thanks!
Adam

@aryehraber
Copy link
Author

Apologies for the delay on this, we're preparing to launch our first product so it's been all hands on deck. I carved out some time this morning to think about this more deeply and try out a few things.

I added an additional config option to record averages before the underThreshold check. This works, but requires 2 separate record() calls (https://github.com/laravel/pulse/pull/284/files#diff-5e3bbf8abb7ea480bdaebfd2fe9ddd42580ca4099aecd092a078285c3fe04abdR82-R89).

Screenshot 2024-01-26 at 09 47 49

However, after further testing with values below the threshold only, I quickly realised that the card starts showing the average data without having any recordings for count & max.

Screenshot 2024-01-26 at 09 33 05

To counter this, I added a reject to the Livewire component to remove rows without a "max" value.

The changes work as expected but admittedly the solution is far from clean imho.

Potentially, it makes more sense to be taking averages of the slow jobs themselves, as @abaldwinls mentioned above. I initially found this idea a bit confusing but have come around that this could actually be fine.

Curious to hear your thoughts!

@aryehraber
Copy link
Author

Going to go ahead and close this as there's not been much further discussion and it honestly doesn't feel like the "right" way to go anyways. Happy to re-open or make changes if you want to come back to this!

@aryehraber aryehraber closed this Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants