Re: [tor-bugs] #24218 [Metrics/Website]: Implement new metrics-web module for IPv6 relay statistics

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#24218: Implement new metrics-web module for IPv6 relay statistics
-----------------------------+------------------------------
 Reporter:  karsten          |          Owner:  metrics-team
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  Metrics/Website  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------

Comment (by karsten):

 Replying to [comment:1 iwakeh]:
 > Moved this to sub-component Website rather than Statistics.

 Heh, that's where all the tickets in Statistics came from when we split up
 Website into data-aggregation parts (Statistics) and website/presentation
 parts (Website). Following that logic, this ticket would belong into
 Statistics. But maybe the distinction is too artificial to really make
 sense. I don't feel strongly where we put it, but I think if we pick
 Website we should consider moving most/all other tickets from Statistics
 to Website, too.

 > Replying to [ticket:24218 karsten]:
 > > The sample graphs I made for #23761 are based on some quick-and-dirty
 Java code that we need to rewrite in a more robust and more scalable way
 before putting these graphs on Tor Metrics.
 > >
 > > Here's my plan for implementing this module, and I'm curious to hear
 possible alternatives or improvements:
 > >
 > >  - We start with a design quite similar to the recently added
 [https://gitweb.torproject.org/metrics-web.git/tree/modules/webstats
 webstats module].
 >
 > I'd suggest to use this module addition to modernize the approach for
 data aggregation.  Even though webstats was added last, it only copies the
 old-fashioned style from the pre-existing modules.

 What modernizations do you have in mind?

 > A new approach could also better address your concerns about the scaling
 and performance.
 >
 > > ...This basically means creating:
 > >    - a PostgreSQL database schema for import tables and
 aggregations/views and
 > >    - a Java class to import into the database and run queries.
 >
 > Steps look fine.  Maybe, include the csv creation into the java code,
 too, in order to avoid shell db exports?

 Yes, that's what the webstats module does, too.

 > >  - I believe that the data aggregation won't scale to years of data.
 My hope is that we can solve this in the database by using some triggers
 to only include newly added data in the aggregation.
 >
 > As said above, we should use this additional module to
 improve&modernize.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24218#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs