All open source developers are curious, so to keep the interest (and 
promote Roundup on PyPy, for example), it would nice to have some stats 
displayed at the bottom of Roundup pages.

Roundup 1.4.19, Python 2.7.1, MySQL XXX
SQL Queries: XXX, Request Time: XXXsec.

Note that there are timing stats gathered
and displayed (in a very ugly way) if the 
CGI_SHOW_TIMING environment variable is set.

So that could be the source for your data.

I am going to mark this as an rfe.

Hi Anatoly:

Does: https://wiki.roundup-tracker.org/AddAboutPage help address
part of your issue?

-- rouilj

Hi John.

My biggest grief is RoundUp router and Jinja2 engine. )

While it is nice to see what kind of information is available, it is still
not visible in the footer
of https://issues.roundup-tracker.org/ and I don't see any stats at all.

MySQL XXX, SQL Queries: XXX, Request Time: XXXsec.

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

[image: image.png]

Hi Anatoly:

In message <CAPkN8xJTHHJoqPM-kiyGMH3S5m+oMfZ38kDP6aTovHwoYc4CZQ@mail.gmail.com>
,
anatoly techtonik writes:
>My biggest grief is RoundUp router and Jinja2 engine. )

The jinja2 stuff has some updates thanks to Christof. I think
it's more secure by default now and there have been some page
additions as well.

>While it is nice to see what kind of information is available, it is still
>not visible in the footer
>of https://issues.roundup-tracker.org/ and I don't see any stats at all.

We could add the python and roundup versions. Both of those can be
made available by a simple extension and a corresponding template
change. For the record: Roundup version: 1.6.1, Python Version: 2.7.12.

But why would we want to spam people with performance stat info? It's kind
of meaningless unless you know the roundup code.

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

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

The way the stats are currently added is to replace the </body> tag
when rendering the page. Currently there are two formats for rendering
the stats. One is as a paragraph and one is as a comment. You could
add a third to render as a script in json form when the environment
variable is set to JSON.

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.

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.

Have a great day.

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

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.

I have opened issue2551153 to expose timing data as Server-Timing
headers.

This should make it available to various development tools.

Also you can add a stat reporting to templating utils to get
response time.

E.G. in extensions/templating.py add:

  def report_stats(client):
    return '<p><small>Generated in %0.3fs<small></p>\n'%(time.time()-
client.start)

call it in page.html using:

  <div tal:replace="structure 
python:utils.report_stats(request.client)"></div>