[tor-bugs] #10192 [Pluggable transport]: websocket-server seems to be (very) slow

[Tor Bug Tracker & Wiki]

#10192: websocket-server seems to be (very) slow
-------------------------------------+-------------------------------
     Reporter:  Aymeric              |      Owner:  asn
         Type:  defect               |     Status:  needs_information
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+-------------------------------

Comment (by Aymeric):

 Yes the client is a browser doing the OP (still the same projects see
 http://www.peersm.com and https://www.github.com/Ayms/node-Tor), Browser1
 (left) is sending a file to Browser2 (right) transiting through Tor and
 relayed by the ORDB.

 I have tried above to give the average CPU and bandwidth performances. For
 the CPU it's computed on iteration on Tor cells (ie how many time to
 handle x Tor cells), so in the browser this gives for example the
 performances for javascript crypto which is what impacts most performances
 (encrypt/decrypt/hash x times for x nodes in the path)

 The ORDB shows small performances because it's a very limited server, I
 must upgrade it, but we don't care about it here.

 The target is to have a speed between the two browsers equal to the upload
 bandwidth (600 kbps), we see that Browser1 is faster than that, for the
 tests it's sending packets at 800 kbps and I can clearly see that tor1 can
 not exceed 250/300 kbps, it's very obvious if I monitor at the same time
 the bufferedAmount for WebSocket and browser2 gets a rate of 250/300 kbps
 max.

 I have replaced tor1 by a node of mine, same server as ORDB handing
 WebSockets, so not very fast, but can at least handle 1 Mbps and then the
 final rate I get for Browser2 is 400/500 kbps (then limited by the ORDB)

 Now it's possible that I have an upload bandwidth limitation between my
 browser and tor1 but this seems unlikely, because the limitation is always
 the same and I have tested tor1 as a normal OR and the download bandwidth
 is in the average.

 That's why I think there is an issue with tor1 websocket-server and/or
 pipe to the OR port.

 If true, then you get this limitation for flash proxys traffic, I suppose
 you have tested it but probably it would be good to test it again, maybe
 nobody noticed it because most of the traffic is supposed to be the
 download way (maybe I should test with my ws node connected to browser1
 and tor1 connected to browser2 to see if the limitation is both ways, I
 did not try).

 I don't know if it can be valid for your code but I remember when I did
 https://github.com/Ayms/websocket that you can easily mess up with the
 code for ws encode/decode and get really poor performances.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10192#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online