Handle debug-level Tor log severity efficiently
Configure your Vidalia to listen to debug-level Tor logs, leave the message window open, and then do something active with your Tor. Vidalia will go nuts trying to keep up with displaying all the lines, resizing them, and whatever else it's trying to do. It's too inefficient handling each new line, and trying to do thousands of them at once just overwhelms it.
Why? What can we do to fix or mitigate? If we can't fix, maybe we should make it more discouraged to click the 'debug' button?
While I'm at it, why does Vidalia set up its own log files from the message window, when it could configure Tor so Tor does the logging?
Activity
Replying to arma:
Configure your Vidalia to listen to debug-level Tor logs, leave the message window open, and then do something active with your Tor. Vidalia will go nuts trying to keep up with displaying all the lines, resizing them, and whatever else it's trying to do. It's too inefficient handling each new line, and trying to do thousands of them at once just overwhelms it.
Why? What can we do to fix or mitigate? If we can't fix, maybe we should make it more discouraged to click the 'debug' button?
True, we can test with a QTextEdit, but if it is too much text it won't be good either, since it'd be more a drawing problem than a processing one. I had experience this issue with QTextEdits now that I think about it.
This is why I'd like to see Vidalia with a GUI in which you have 2 modes: Standard and Advanced. In the Standard there's a really basic use of Tor, mostly to use as a client. And in the Advanced mode, you have all the detail configuration and the possibility to see debug messages. This way, a user has to enable the Advanced mode, and then enable the debug logging part.
While I'm at it, why does Vidalia set up its own log files from the message window, when it could configure Tor so Tor does the logging?
I don't know what was the original idea, but I agree Vidalia should set up its own log files for logs about Vidalia itself, and not Tor.
The best way to handle this that I can think of is to disable debug message at all in Vidalia, since Tor can log to a file by its own, and Vidalia's debug messages can go to a different file.
Most likely the issue isn't so much drawing the volume of logs, but rather that each DEBUG log event triggers a UI update. Arm ran into this problem too, and I'm addressing it by coalescing events if they occur too frequently (by default limiting UI updates to once every 300 ms). For the code involved look for the 'features.log.maxRefreshRate' config option in: https://svn.torproject.org/svn/arm/trunk/src/interface/logPanel.py
I have yet to stress test this on especially heavily loaded relays so it might not be a silver bullet, but thus far it seems to be working well at keeping the interface nice and responsive at the DEBUG runlevel. Cheers! -Damian
Replying to atagar:
Most likely the issue isn't so much drawing the volume of logs, but rather that each DEBUG log event triggers a UI update. Arm ran into this problem too, and I'm addressing it by coalescing events if they occur too frequently (by default limiting UI updates to once every 300 ms). For the code involved look for the 'features.log.maxRefreshRate' config option in: https://svn.torproject.org/svn/arm/trunk/src/interface/logPanel.py
Actually, it is a problem of drawing, if you update the GUI once every 300ms, but you "feed" the QTextEdit or whatever chunks of text of 400 lines, the drawing will be a problem. I experienced this with an application that generated equation systems, I generate one "block of equations" (5 lines average) and then add it to a QTextEdit that had all the blocks, the generation was almost costless, but what almost crashed everything was Qt trying to draw everything I asked it to. I think it isn't the same as ARM's problem, since it's a console application, but maybe somebody else has another idea/experience. I still think taking out debug messages will be the way to go here, and fixing the logging inconsistencies. I can't think of a Qt way to handle that much text without experiencing odd issues.
Replying to arma:
While I'm at it, why does Vidalia set up its own log files from the message window, when it could configure Tor so Tor does the logging?
The controller might run remotely/Tor might not have write access to the paths that Vidalia has write access to. Making Tor log if possible and only if not possible have Vidalia be a logging proxy sounds saner than completely removing that functionality.
A couple of weeks ago I added a minor tweak to the message log part that has fixed this issue, although more testing will be needed.
Currently it isn't in Vidalia's svn, but in the reorderui branch of my git repo. So until that patch is committed I won't close this, but just wanted to let everyone know this is fixed.
A minor patch that fixes the drawing problem
Trac:
Status: new to needs_review
Points: N/A to N/A
Actualpoints: N/A to N/AOk, this has been committed to the svn.
Trac:
Status: needs_review to closed
Resolution: N/A to fixed- Trac closed
closed
- edmanm mentioned in issue #2500 (closed)
mentioned in issue #2500 (closed)