[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #13362 [Onionoo]: Make Onionoo's logs more useful
#13362: Make Onionoo's logs more useful
-----------------------------+----------------------------
Reporter: karsten | Owner:
Type: enhancement | Status: needs_revision
Priority: normal | Milestone:
Component: Onionoo | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
-----------------------------+----------------------------
Comment (by leeroy):
From reading here and the child tickets it sounds like the improvements
will need to consider the import of archives. So maybe I should look into
obtaining thresholds including that possibility first? When the backend
imports archives during the update the entire process takes 12hours (+ a
scaling modifier of ~1.3 depending on availability of cpu cores for load
heavy parts like reading consensus). When the updater is run on recent
data, for the first time, a similar behavior occurs with a baseline of 1
hour. Other updates which apply only recent updates of n consensus
intervals (having n << 72) are relatively short operations.
* In any case how should the thresholds be defined? In a file? These
thresholds will be sensitive to improvements in the code. Say the import
of data is improved, now the thresholds will need to be easily updated.
* Other possibilities may include: defining a test (run with rest of the
tests) to profile performance, and have the import and update
functionality provide a hint as to how much data is being processed.
* What kind of additional logging, for the frontend, should be added?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13362#comment:11>
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