I was under the impression thatbatchstats buffers up to a certain amount of updates, so let's say 100 workspaces all report their agent stats at the same time, all 100 stats would be written in one go. Is this not the case? (Please note, I'm not making a case for or against the batcher here, just wondering if the premise is correct?)

I was under the impression thatbatchstats buffers up to a certain amount of updates, so let's say 100 workspaces all report their agent stats at the same time, all 100 stats would be written in one go. Is this not the case? (Please note, I'm not making a case for or against the batcher here, just wondering if the premise is correct?)

Yep, up to 1024 stats updates.

The batcher is totally valid, but my concern is that we are only saving 1 db call when reporting the stat already takes 7-8 db calls to get to that point, and continues to use the DB afterwards too. In return we lose the ability to return an error on failed writes, and a good bit of code to manage this buffer.

Going to continue removing some batchers on this branch and going to scaletest the impact to see if these changes are safe to merge

The batcher is totally valid, but my concern is that we are only saving 1 db call when reporting the stat already takes 7-8 db calls to get to that point, and continues to use the DB afterwards too. In return we lose the ability to return an error on failed writes, and a good bit of code to manage this buffer.

I see, that's fair reasoning. I believe writing to this table (agent stats) used to be more expensive as we kept 6 months of data in it. Now we only keep about 1 day.

Edit: Still, there's a big difference between read and write queries. I assume most of those 8 DB calls are read-only?

@mafredri Thanks for bringing this up, I do share your concerns since it's a write operation, so I've went ahead and made an alternate PR (#13418) where we keep these structures in place under theworkspacestats.Reporter. I'd also like your perspective on scale testing: If we do a scale test and find that these batchers are not showing any impact (that we measure), would you still want to keep them for posterity or would you be in favor of removing them?

@mafredri Thanks for bringing this up, I do share your concerns since it's a write operation, so I've went ahead and made an alternate PR (#13418) where we keep these structures in place under theworkspacestats.Reporter.

👍🏻

I'd also like your perspective on scale testing: If we do a scale test and find that these batchers are not showing any impact (that we measure), would you still want to keep them for posterity or would you be in favor of removing them?

If we find that they're not beneficial, I'm fine with removing them entirely. We can always dig in the git history if we realize we need them back.

Thanks for this data, glad to close and happy to know these are working as intended!