Closed ercsctt closed 5 months ago
Hi @ercsctt,
This is intentional. Buckets hold 1/60th of the window they belong to.
60 is somewhat arbitrary, but there are two reasons we chose it:
pulse_entries
table to fill in the oldest part of the window where the oldest bucket would fall partially inside and outside the window. This allows us to do rolling window aggregation down to the second. I.e. we can show windows like "the past hour" rather than tumbling windows like "10am - 11am". 60 buckets seems like a good balance that keeps the number of raw entries queried to a minimum without creating too many buckets.window | seconds | 1/60th | bucket size |
---|---|---|---|
1 hour | 3,600 | 60 | 1 minute |
6 hours | 21,600 | 360 | 6 minutes |
24 hours | 86,400 | 1,440 | 24 minutes |
7 days | 604,800 | 10,800 | 2 hours, 48 minutes |
I explained the approach in more detail here: https://www.youtube.com/watch?v=9cliEswA8CA&pp=ygUYbGFyYXZlbCB3b3JsZHdpZGUgbWVldHVw
Pulse Version
1.2.3
Laravel Version
11.10.0
PHP Version
8.1
Livewire Version
3.4.9
Database Driver & Version
No response
Description
Aggregate bucket timestamps are based on epoch timestamps in seconds; however, "periods" are in minutes. It appears there's a logical error here.
Example: 2 pulse_aggregates rows for the same type and key. The period is 7 days (10080 minutes). The bucket timestamps are 1717077600 and 1717087680, a difference of 10,080 seconds.
Surely, since the timestamps are in seconds, the difference should be 604,800 seconds to represent a 7-day gap?
I'm unsure if this is an oversight or intended. Happy to produce a PR to fix!
Steps To Reproduce
Install pulse in a fresh laravel project, and ensure data is being stored in pulse_entries and pulse_aggregations.