On March 6, 2015 11:32:01 PM Tom van der Woerdt info@tvdw.eu wrote:
Hi Tom,
Sebastian Urbach schreef op 06/03/15 om 21:52:
Dear list members,
I hope that some of you compared 0.2.5.10 with 0.2.6.x regarding the performance (ticket 9682). How big/small is the difference in the wild ? I would appreciate it if someone with Linux / BSD could say a few words ;-)
Hi Sebastian,
As far as I can tell the change happened between 0.2.6.2 and 0.2.6.3 so I'll describe the performance difference between those.
You're right, got 0.2.5.10 stuck in my head because it's the last stable release ;-) The patch came up with 0.2.6.3, indeed.
Just had a look on a server of mine that is bottlenecked by the CPU. I noticed that there was indeed a big drop in CPU usage. However, there was also a similar drop in network usage, most likely caused by the restart. It took about a week to fully recover to normal levels.
It is incredibly hard to tell from the data whether there was a big performance difference as a direct result of the 0.2.6.2->0.2.6.3 upgrade. It's definitely not going to be a 10% improvement, as far as I can tell.
Hard to tell pretty much says it all :-( Not much of a change. Now the multithread feature becomes the last hope :-)
Despite my nodes all running with 'NumCPUs 2', none of the worker queues seem to be doing much :
$ ps H -o etime,time,args -u toranon | grep node2 3-01:46:17 1-20:35:33 /usr/bin/tor -f /etc/tor/torrc-node2 3-01:46:13 00:17:09 /usr/bin/tor -f /etc/tor/torrc-node2 3-01:46:13 00:17:09 /usr/bin/tor -f /etc/tor/torrc-node2
If those threads are what the patch addressed, I'm afraid it's not going to have a massive impact.
In case it's relevant: these measurements are taken from an exit relay with two processes each doing ~150Mbit/s (x2 if you count up+down).
Upgrade was done at 2015-02-24 21:26, relevant graphs : * cpu: http://www.imgdumper.nl/uploads8/54fa2a823bc62/54fa2a823434f-cpu.png * network: http://www.imgdumper.nl/uploads8/54fa2a8ce3db5/54fa2a8cdd05c-if_eth1.png
Thanks gor your reply, domehow i expected it zo be more of a boost after reading Nick's text:
https://blog.torproject.org/blog/coming-tor-026
On Sat, Mar 07, 2015 at 12:53:39PM +0100, Sebastian Urbach wrote:
Hard to tell pretty much says it all :-( Not much of a change. Now the multithread feature becomes the last hope :-)
Thanks gor your reply, domehow i expected it zo be more of a boost after reading Nick's text:
The main reason I'm excited about https://trac.torproject.org/projects/tor/ticket/9682 is because it should handle high circuit creation loads better.
When the botnet hit a few years ago, there were suddenly five million new Tor clients all sending create cells pretty often: https://trac.torproject.org/projects/tor/ticket/9657 It got to the point where many relays were at 100% cpu and still rejecting many of the create cells they received. And they were waiting in the queue and timing out, rather than being rejected preemptively. We added some logic to count (for that particular relay) how long it takes us to handle a create cell, and then when we had so many queued already that we know we won't get to the new one in time, we rejected it early.
But that logic never actually worked -- cpuworkers spent a lot of time idle, because we only measured "time to process the create cell", not "time for the main thread to notice that the cpuworker can handle another one, and then time to give it to the cpuworker, and then time to process the create cell": https://trac.torproject.org/projects/tor/ticket/9574#comment:29
This new patch in 0.2.6.3 greatly reduces the first two of these three items.
So in summary, in times when create cell load becomes huge again, we should be able to handle many more of them than before.
--Roger
tor-relays@lists.torproject.org
-
Roger Dingledine -
Sebastian Urbach