Hi Anatoly:

In message
<CAPkN8xLtHuYn1zi7kU_RvwQaqmNzmjQugGzV=EDmPy3MNnvFRw@mail.gmail.com> ,
anatoly techtonik writes:
>On Tue, Jun 2, 2020 at 5:55 PM John Rouillard
><issues@roundup-tracker.org> wrote:
>>
>> But why would we want to spam people with performance stat info? It's kind
>> of meaningless unless you know the roundup code.
>
>It is not spam if it is just a site footer.
>
>Performance stats are meaningful for everyone who ever experienced how
>slow alternative trackers could be. Jira could take 20 seconds.

Been there done that at my former job.

>Imagine waiting for the bug list for 20 seconds every time you open
>tracker. It useful not only for those familiar with RoundUp code, but
>also for those who want to know more about it. For some stats speak
>better than reviews.  And yes, it is nice to see that stats are also
>open source. )

The problem is that the response time is not just the server
component, which is the only one you are tanking about.  The browser
has to finish transferring and rendering the html before the user is
able to interact. Hence RUM.

>> Also it's not RUM. I have some RUM like stats installed in my page
>> templates to get info like load/render time.
>
>What is RUM?

It's an alcoholic beverage made from ... Oh

  https://en.wikipedia.org/wiki/Real_user_monitoring

Use google to search for RUM http. Lots of hits.

Basically a timing framework that runs client side. It includes the time
of transfer, rendering etc. Usually triggers by the onload event.

>> >I guess the Python code that does HTML formatting is needed to be
>> >itself template independent, but I'd prefer the function to return
>> >JSON so that web interface part could format it to their liking.
>>
>> So you want an output format like:
>>
>>  <script nonce="random_nonce">
>>  timing_stats = { 'filtering': 2.3, 'elapsed': 3.2, ...}
>>  </script>
>>
>> Is that right?
>
>I was thinking about an endpoint like `/stats/json`, but then it will be
>separate http request, and at least metrics need to be tied to request
>data. Maybe headers is the best way to transfer that, but then I am not
>sure how to read HTTP headers from template.

You wouldn't have it in the headers. There are no headers when the
template is being rendered. What template code do you mean?  Server
side TAL/jinja2? Do you mean a client side templating system like
mustache?

>It will definitely require some JS and starts to sound complicated.

Somebody would have to build an entire framework to gather, store, and
allow retrieval of the data outside of the http transaction.

>Maybe for template it is better to get a dict in a global template variable
>called `g_stats` or something. `g_` prefix for being global and easily
>greppable in docs. JSON is good for outside data export, like versions,
>but not for server side render.
>
>> The problem with getting these into the template is that the timing
>> stats are generated just before the html file is returned. It has to
>> be this way since the template rendering needs to be included in the
>> stats. So it can't be rendered inside the tal/jinja2/chameleon engine.
>
>So it is kind of "post-processing" step.

Correct. If you are not going to build an entire statistics
storage/retrieval mechanism, it has to be done as the last (or near
last) step in the output pipeline.

>Makes sense if template rendering is critical.

Performance stats (using cProfile) show most of the time in the
templating engine (for TAL).

>Then making stats a template variable is not really
>useful at all. In addition many framework could actually query database
>during rendering of the template, thus saving the memory on caching
>the data and passing it to the template.

All the database queries and automatic caching occur as part of
expanding the template. So I am not sure what you are getting at here.

>> This also brings up an interesting point, the JSON endpoint doesn't
>> have a method for generating or returning stats to the caller.
>
>I did't even know there is a JSON endpoint already. =)

The 2.0 release currently in beta has a REST endpoint. It returns JSON
(and optionally XML if the right libraries are installed).

You probably want to sign up for the roundup-users mailing list if you
are going to be using roundup. The links on the web site to the 2.0
docs and the rest docs are:

  http://www.roundup-tracker.org/dev-docs/docs.html
  http://www.roundup-tracker.org/dev-docs/docs/rest.html

Also as of early this morning the REST interface it can report stats
using the @stats=true query parameter. (Took me 5 times longer to
write and validate the test cases as it took to implement the feature
8-/.)

Have a great day.