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. 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. )

> 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?

> >MySQL XXX, SQL Queries: XXX, Request Time: XXXsec.
>
> The references to CGI_SHOW_TIMINGS are in roundup/cgi/client.py
> Client::renderContext. Did you investigate how they put in Cache
> hits/misses, timings etc? Also it looks like it may just generate
> hyperdb level stats. I am not sure how far down the stack the stats
> generation is done, so you may not have your mysql/postgresql database
> stats.

I didn't put a lot of research into that. I guess each metric deserves a
separate blog even if it is trivial to get without performance overhead,
and ten times more worthy is it is non-trivial or expensive. =)

> >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. It will definitely require
some JS and starts to sound complicated.

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. Makes sense if template
rendering is critical. 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.

> As I note these stats are hyperdb and overall rendering info. It could
> be possible to link self.db['stats'] into the request object as
> request/db/stats. This would be a snapshot at the time, but if you
> accessed it only at the end of the template, you would have all the
> stats except for the overall time. You might be able to calculate that
> from the client.start time.
>
> 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. =)