Luciana Lima Brito <lubrito@posteo.net> writes:

> On Fri, 30 Apr 2021 18:05:15 +0100
> Christopher Baines <mail@cbaines.net> wrote:
>
>> >
>> > Task 1: Add instrumentation to identify the slow parts of processing
>> > new revisions:
>> >
>> >   - Implementing a chart over time to identify slow parts:
>> > 	- The chart should consider two aspects, the time took by
>> > 	  each specific part, and its name, for identification
>> >       purpose. A bar chart is a good candidate for this task, it is
>> >       simple and can show the whole picture of the time taken by the
>> > 	  system to process a new revision;
>> > 	- The bars on the chart should be sorted in order of
>> >       precedence of the process in the X axis, and its height, which
>> >       is determined by the time it takes, measured in the Y
>> > 	  axis;
>>
>> I'm not sure what you mean by "precedence of the process" here?
>
> As we are concerned only with the time each process takes, and each bar
> on the chart will be presented side by side, the order of the bars would
> be the order that the processes appear. If you prefer, they could be
> sorted alphabetically, or by time taken.

Ok, I think I follow.

Currently the timing of various sections of the process includes timing
smaller sections, and that may complicate reading the chart, since it
won't convey which timed sections include other timed sections. Does
that make sense?

>> > 	- The charts should work as picture-logs for timing;
>> > 	- A chart should be generated for each new revision in real
>> > 	  time; 
>> 
>> It would be good to say explicitly how the chart will be stored, since
>> "the same way as the logs already are" is quite vague.
>
> I misunderstood this point so this part about storing the chart is
> completely messed. But I think now I got it. Let me correct the last
> point and add some more:
>   ...
> 	- The time is already being computed for each part and it
> 	  is shown in the logs, the same data can be used to build the charts.
> 	  The data to build the chart for each revision could be
> 	  stored as a new table in the database*, first in parts, for
> 	  when a revision is still being processed, then combining their
> 	  parts when the processing is finished.
> 	- The new table on the database should store three information:
> 	  the job_id, the action, and the time taken.
> 	- Then, when one wants to see the chart, this table is queried
> 	  and the chart is rendered as html.
>
> * Although the information is already in the log, it is stored as a
>   text, so it is harder to get the names of the actions and the time
>   taken by each, so I think that create a new table, with only these
>   values, is more suitable.

Great, this is a good amount of detail.