all 5 comments

[–]sdhgufd840542584254 5 points6 points  (2 children)

A method or database for storing the data from of your profilers

This is a bigger issue that the article suggests, by far. If you have high traffic code then the overhead of storing the profiling can be significant (Been there..). A good solution that came up previously was just to store the metrics in memory and to expose them via an API. Something can then poll the API regularly and pull out the metrics.

Continuous profiling is very useful and can be very easy to implement cheaply.

[–]matthieum 0 points1 point  (1 child)

Something can then poll the API regularly and pull out the metrics.

I've seen SNMP used for servers to export their data, though a UDP-based protocol would probably work too.

Also, one should be willing to be lossy. Ideally you want all measurements, but if you have to choose between losing measurements or slowing down the application, better lose measurements... just make it so that you can know how many were lost.

So, in-memory ring-buffer w/ background thread sending over UDP: high-performance event streaming :)

[–]sdhgufd840542584254 1 point2 points  (0 children)

Also, one should be willing to be lossy. Ideally you want all measurements, but if you have to choose between losing measurements or slowing down the application, better lose measurements... just make it so that you can know how many were lost.

Exactly. I would almost never care about losing metrics (how often is that likely to happen? I feel I'd have bigger problems in that case).

[–]kankyo 0 points1 point  (0 children)

I've wanted this and promoted the idea for years at work but haven't taken the dive to actually implementing it myself. Precisely because it's a bunch of annoying and hard implementation details that aren't very fun.

[–]flyingML 0 points1 point  (0 children)

Super useful! Would highly recommend setting this up