[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8902 [Tor]: Rumors that hidden services have trouble scaling to 100 concurrent connections



#8902: Rumors that hidden services have trouble scaling to 100 concurrent
connections
------------------------+-----------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.???
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  SponsorR tor-hs
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-----------------------------

Comment (by dgoulet):

 I've collected profiling data with perf and here is the result I have.

 My use case is simple, I have an IRC server behind an HS on a remote far
 away server from me. I use torsocks with irctorture
 (git://git.breakpoint.cc/fw/irctorture.git) and hammer the server. Each
 torsocks connection uses a user/password different thus putting every
 irctorture client on its own circuit. I spawned 100 irctorture tests for a
 duration of 10 minutes. I did multiple runs and the perf data shown below
 is consistant at each run.

 You can find the perf data of the top 5 calls:

 https://people.torproject.org/~dgoulet/tor-hs-perf-100-circ.png

 You can't see it on the pic but the next call is this which I thought was
 quite important to provide:

 {{{

 -   3.85%  tor  [.] compute_weighted_bandwidths
 â
    - compute_weighted_bandwidths
 â
       - 96.97% node_sl_choose_by_bandwidth
 â
            router_choose_random_node
 â
            circuit_establish_circuit
 â
          - circuit_launch_by_extend_info
 â
             - 79.17% rend_service_introduce
 â
                  rend_process_relay_cell
 â
                  connection_edge_process_relay_cell
 â
                  circuit_receive_relay_cell
 â
                  command_process_cell
 â
                  channel_tls_handle_cell
 â
                  connection_or_process_cells_from_inbuf
 â
                  connection_handle_read_impl
 â
                  conn_read_callback
 â
                  event_base_loop
 â
                  do_main_loop
 â
                  tor_main
 â
                  __libc_start_main
 â
                  _start
 }}}

 Clearly seems like most of our time is in {{{rend_service_introduce()}}}.
 Also, {{{node_get_prim_orport()}}} using 13.60% of the CPU!, I feel like
 there is maybe something here that we can investiguate for improvement.

 Note that the HS after a while prints these so it is loaded but also seems
 limited by the guard.

 {{{
 Nov 08 06:51:37.000 [warn] Your Guard [scrubbed] is failing a very large
 amount of circuits. Most likely this means the Tor network is overloaded,
 but it could also mean an attack against you or potentially the guard
 itself. Success counts are 122/244. Use counts are 60/60. 212 circuits
 completed, 0 were unusable, 90 collapsed, and 5 timed out. For reference,
 your timeout cutoff is 60 seconds.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8902#comment:10>
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