What are the thoughts around putting time tracking stats around LUA
calls? Just really basic info like how long a request spent running LUA
code. Similar to how we already have metrics for time spent in queue,
connecting, waiting on response, etc.
Currently I accomplish this manually by grabbing the timestamp at the
beginning and end of all LUA actions, store the duration in a
transaction variable, and add that variable to the log. But I was
wondering if this should instead have a native solution.
I see we already have `tune.lua.service-timeout`, so it appears some
timing data is already tracked. However one difference between that data
and my custom implementation is that mine includes sleep time. So we
might want to expose the LUA time as 2 different metrics: one as CPU run
time, and another as wall clock time.
The use case is that as we put more code into LUA scripts, we want to be
aware of the impact this code is having on the performance of the
requests, and the response times.
-Patrick
calls? Just really basic info like how long a request spent running LUA
code. Similar to how we already have metrics for time spent in queue,
connecting, waiting on response, etc.
Currently I accomplish this manually by grabbing the timestamp at the
beginning and end of all LUA actions, store the duration in a
transaction variable, and add that variable to the log. But I was
wondering if this should instead have a native solution.
I see we already have `tune.lua.service-timeout`, so it appears some
timing data is already tracked. However one difference between that data
and my custom implementation is that mine includes sleep time. So we
might want to expose the LUA time as 2 different metrics: one as CPU run
time, and another as wall clock time.
The use case is that as we put more code into LUA scripts, we want to be
aware of the impact this code is having on the performance of the
requests, and the response times.
-Patrick
