<div dir="ltr"><div><div><div><div>Perhaps a crazy idea, but it should work and perform quite well....<br></div><div><br>Non 18+ compatible solution:<br></div>- Keep track of refs. They are monotonically increasing across all schedulers. Create a timer somewhere that periodically saves to an ets table {make_ref(),os:timestamp()} (or some other data structure). When checking how old a message is, find which two refs in ETS your ref belongs to. That was the timeframe of that message.<br><br></div>18+ compatible solution:<br></div>- Do this for every scheduler in the system, because make_ref will be per scheduler then. For every message, you must call <span class="">erlang:system_info(scheduler_id)<br><br><br></span></div><span class="">Sergej<br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 29, 2015 at 11:12 AM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For various reasons, I want a metric that measures how long messages<br>
spend in a process message queue. The process is a gen_server, if that<br>
has any bearing on the solution. Also, this is for production, so it<br>
will be always-on and must be low-impact.<br>
<br>
I could do this by timestamping _every_ message sent to the process<br>
and then reporting the deltas, but I think that's ugly.<br>
<br>
I thought of posting a message to self(), with a timestamp and then<br>
measuring the delta. I could then post another one as soon as that<br>
message is processed. Obviously, this leaves the process continually<br>
looping, which is not good.<br>
<br>
So, instead, I could use erlang:send_after, but that requires two<br>
messages: a delayed one triggered by erlang:send_after, and an<br>
immediate one for measuring the delay.<br>
<br>
That's a bit complicated.<br>
<br>
Would it be sensible to send a message, with erlang:send_after, with<br>
the _expected_ timestamp, and then compute the delta from that?<br>
<br>
Or, alternatively, what other ways could I measure how long a process<br>
is taking to handle its message queue?<br>
<br>
Thanks,<br>
Roger.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>