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:
-----------------------------+------------------------------
Changes (by iwakeh):

 * component:  Metrics/Statistics => Metrics/Website


Comment:

 Moved this to sub-component Website rather than Statistics.

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

 >
 >  - 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:1>
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