You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It is impossible to understand what working_time means without going to the code or without analyzing explicitly the log events.
It is necessary to document how it is calculated. What is the "duration" of some event types etc.
Describe the solution you'd like
Here is the small summary of how I understand the working_time:
UI collects the "events" when user interacts with buttons etc.
The structure of one single record in the event series described here
2.1 Each record has it's own timestamp
2.2 Some records has a duration
UI sends the message with the series of events by 3 triggers:
3.1. When user click "Save"
3.2 When user loads the job
3.3 Periodically by timer
When the "events" message (you can find it in Network page in your browser if needed) arrives, server calculates the working time and updates the payload with the calculated working_time.
Here is the example of how this working_time is calculated.
If you go from the bottom to the top you'll see the first event with working_time 0. Second one is the timestamp of the first - the timestamp of the current event. Third is the second timestamp - current timestamp (third one) etc.
Let's say we've pushed the "play" button and changed 30 frames from frame 10 to frame 40. This means that UI would generate 30 change:frame events. Instead, these 30 events are collapsed in 1 event with a duration of 4 seconds and a timestamp of the first change:event.
To summarize the above.
Each event has it's own timestamp
Some event types has a duration. One of these kind is change:frame. Others has a duration as 0.
If there is a duration > 0 for the event, the duration is added to the working_time
A note about the time limits. If the time difference between the current timestamp and previous timestamp is <= 100 s. then the working time is calculated just like it is described above. If the time difference is > 100s, the working_time is 0 for the current event and the working_time is calculated from the second timestamp as usual.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
- Parsing JSON payloads to get `working_time` in general leads to low
performance in Clickhouse requests. This patch will not fix it right
now, but with this patch, after a period of time we may switch to new
quick approach to calculate working time.
- There will not be a lot of `send:working_time` events, we may store
this scope of events for a longer time (e.g. 5 years instead of one by
default).
- Finally storing working time in such events like `click:element` or
`send:exception`, or `debug:info` seems not logical.
- Also, the history showed, that as result in different bugs, these
events may sometime lose information about `job_id`, `task_id`, etc.
Resolved#7884
Actions before raising this issue
Is your feature request related to a problem? Please describe.
It is impossible to understand what working_time means without going to the code or without analyzing explicitly the log events.
It is necessary to document how it is calculated. What is the "duration" of some event types etc.
Describe the solution you'd like
Here is the small summary of how I understand the working_time:
UI collects the "events" when user interacts with buttons etc.
The structure of one single record in the event series described here
2.1 Each record has it's own timestamp
2.2 Some records has a duration
UI sends the message with the series of events by 3 triggers:
3.1. When user click "Save"
3.2 When user loads the job
3.3 Periodically by timer
When the "events" message (you can find it in Network page in your browser if needed) arrives, server calculates the working time and updates the payload with the calculated working_time.
Here is the example of how this working_time is calculated.
If you go from the bottom to the top you'll see the first event with working_time 0. Second one is the timestamp of the first - the timestamp of the current event. Third is the second timestamp - current timestamp (third one) etc.
working_time, timestamp, event
0.355 2024-04-28T18:06:46.099Z drag:object
0.392 2024-04-28T18:06:45.744Z drag:object
0.451 2024-04-28T18:06:45.352Z drag:object
0.497 2024-04-28T18:06:44.901Z drag:object
0.593 2024-04-28T18:06:44.404Z drag:object
0.565 2024-04-28T18:06:43.811Z drag:object
0 2024-04-28T18:06:43.246Z drag:object
There are some events that has a duration field. 2 of them are change:frame and save:job.
Working_time for these types is: duration of the event + time difference between the previous timestamp and a current timestamp.
Example:
working_time, timestamp, event
4.089 2024-04-28T18:07:01.346Z change:frame
0.662 2024-04-28T18:07:00.225Z drag:object
0.466 2024-04-28T18:06:59.563Z resize:object
0.582 2024-04-28T18:06:59.097Z drag:object
1.048 2024-04-28T18:06:58.515Z drag:object
Let's say we've pushed the "play" button and changed 30 frames from frame 10 to frame 40. This means that UI would generate 30 change:frame events. Instead, these 30 events are collapsed in 1 event with a duration of 4 seconds and a timestamp of the first change:event.
To summarize the above.
Each event has it's own timestamp
Some event types has a duration. One of these kind is change:frame. Others has a duration as 0.
If there is a duration > 0 for the event, the duration is added to the working_time
A note about the time limits. If the time difference between the current timestamp and previous timestamp is <= 100 s. then the working time is calculated just like it is described above. If the time difference is > 100s, the working_time is 0 for the current event and the working_time is calculated from the second timestamp as usual.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: