Yes, this seems fair and relevant, but like its one of the reasons we’re doing this as a hook where each user can decide exactly which pieces of history they keep around for how long based on their particular event size and frequency… in my example, I’m not keeping history for all metrics, just for some custom ones in a specific namespace/ “event_name”. I guess I’m not sure how general or broad to make the examples, or whether perhaps to make a few examples highlighting these tradeoffs etc? But thanks for the idea of loadtesting, that seems useful, did you use anything that’s an easy reference for me to leverage or just some one-off code you threw away?
bglusman
LostKobrakai
bglusman
Thanks! I see the tz_world discussion here Tz_world / timezone_boundary_builder update
I wonder if maybe should just have a second example that pulls/pushes history from/into Redis or Postgres or something as an alternative for where keeping this data in memory is a concern, but would also like to understand/cover José’s concerns about when to possibly not resend some events and/or when reflecting on tags or other metric metadata may impact the response, so anyone using those who can help me test out the implementation in real world condition, hope to hear from you!
0