Jetty
  1. Jetty
  2. JETTY-93

SelectChannelConnector much to slow in windows

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0.0rc2
    • Component/s: HTTP
    • Labels:
      None
    • Environment:
      jetty6 SVN head from 14:15 CEST 19. July 2006
      2 computers running winxp, connected via 100MBit/s Ethernet

    • Number of attachments :
      2

      Description

      SelectChannelConnector is extremely slow when client AND server run windows. Serving the same ~14MB jar file takes ~88 seconds (163 kB/s) using SelectChannelConnector and ~1 second (11,8 MB/s) using SocketConnector.

      When the client uses a smaller buffer than 32kB (see client example) , the download becomes a bit faster (up to 460 kB/s).
      (unfortunately, javaws 1.5 uses 32kB).
      When the server runs on freebsd and the client on windows, I get about 8-9 MB/s using the SelectChannelConnector.

      I will attach the following:

      • test server which serves the current directory using SelectChannelConnector on port 18080 and SocketConnector on port 18081
      • test client which connects to the server on both ports and measures time and speed
      • a big jarfile which is served

      To reproduce:

      • Insert server hostname in SlowClient.java
      • compile client and server
      • Put SlowServer.class, big.jar and jetty libraries on one windows box and SlowClient.class on another windows box, both being connected via 100MBit ethernet.
      • run server and client
      1. SlowClient.java
        1 kB
        Yug
      2. SlowServer.java
        0.8 kB
        Yug

        Issue Links

          Activity

          Hide
          nik gonzalez added a comment -

          meanwhile, I'll continue with the other experiments.

          Show
          nik gonzalez added a comment - meanwhile, I'll continue with the other experiments.
          Hide
          nik gonzalez added a comment -

          Here's the ethereal file for the socketconnector:
          http://www.yousendit.com/transfer.php?action=download&ufid=D5F2E4BA413BEBB5

          I just tried setting Socket.setSendBufferSize() equal to responsebuffersize (32*1034) and this is what I got (still slow at 100984 milliseconds at 156 kb/s):
          http://rapidshare.de/files/28232735/selectchannelconnector-setsendbuffersize-32k.zip.html

          I tried setting setSendBufferSize to 64k and file transfer was much faster. about 1344 milliseconds at 11738 kb/s-is this an acceptable speed level? the selectsocketconnector had exactly the same speed readings as socketconnector.

          here's the ethereal file for that:
          http://rapidshare.de/files/28232735/selectchannelconnector-setsendbuffersize-32k.zip.html

          Show
          nik gonzalez added a comment - Here's the ethereal file for the socketconnector: http://www.yousendit.com/transfer.php?action=download&ufid=D5F2E4BA413BEBB5 I just tried setting Socket.setSendBufferSize() equal to responsebuffersize (32*1034) and this is what I got (still slow at 100984 milliseconds at 156 kb/s): http://rapidshare.de/files/28232735/selectchannelconnector-setsendbuffersize-32k.zip.html I tried setting setSendBufferSize to 64k and file transfer was much faster. about 1344 milliseconds at 11738 kb/s-is this an acceptable speed level? the selectsocketconnector had exactly the same speed readings as socketconnector. here's the ethereal file for that: http://rapidshare.de/files/28232735/selectchannelconnector-setsendbuffersize-32k.zip.html
          Hide
          Greg Wilkins added a comment -

          I believe the static content handle refactor has fixed this problem (not tested
          first hand, but has been reported as fixed).

          Yug - Can you please test 6.0.0rc2 and reopen this issue if it is not the case.

          Show
          Greg Wilkins added a comment - I believe the static content handle refactor has fixed this problem (not tested first hand, but has been reported as fixed). Yug - Can you please test 6.0.0rc2 and reopen this issue if it is not the case.
          Hide
          Yug added a comment -

          With the latest svn, the windows-windows transferrates are ok.

          SlowClient output windows server - windows client
          SelectChannelConnector
          http://crushinator:18080/big.jar
          bytes read: 14364739
          1609 ms
          speed: 8927 kB/s
          -----------------------------
          SocketConnector
          http://crushinator:18081/big.jar
          bytes read: 14364739
          1250 ms
          speed: 11491 kB/s

          For some odd reason, the SelectChannelConnector is still slow when the client runs on freebsd:

          server windows - client freebsd
          SelectChannelConnector
          bytes read: 14364739
          11177 ms
          speed: 1285 kB/s
          -----------------------------
          SocketConnector
          bytes read: 14364739
          1277 ms
          speed: 11248 kB/s

          Show
          Yug added a comment - With the latest svn, the windows-windows transferrates are ok. SlowClient output windows server - windows client SelectChannelConnector http://crushinator:18080/big.jar bytes read: 14364739 1609 ms speed: 8927 kB/s ----------------------------- SocketConnector http://crushinator:18081/big.jar bytes read: 14364739 1250 ms speed: 11491 kB/s For some odd reason, the SelectChannelConnector is still slow when the client runs on freebsd: server windows - client freebsd SelectChannelConnector bytes read: 14364739 11177 ms speed: 1285 kB/s ----------------------------- SocketConnector bytes read: 14364739 1277 ms speed: 11248 kB/s
          Hide
          Endre Stølsvik added a comment -

          .. but isn't it nevertheless strange that it still is noticable faster when using the SocketConnector?! And in particularly, obviously, on the second scenario windows/freebsd? (what about windows/linux?)

          Btw, this would probably be a 100 Mbps network, so that ~11.5 MBps basically is rather close to the theoretical limit (100/8=12.5, plus TCP/IP overhead)?
          It would be very interesting if one of you could repeat the tests using a setup where you couple those two machines together with a 1Gbps line, to see what it'd really max out at.
          Note that very many boxes these days have a 1Gbps network port, but still most office/home switches are 100Mbps: You could actually just "hotwire" the boxen together w/o using a hub/switch (use static ips). One should load the entire file into memory then, or else the disk will definately limit - and probably use a somewhat larger file too, or else it will go too fast to give reliable measurements.

          In a normal (not extremely-high-amount-of-users) environment, it seems like it would be smarter to still stick with the good'ol SocketConnector, rather than with the new'n'flash, obviously still not quite broken in SelectChannel stuff?

          Show
          Endre Stølsvik added a comment - .. but isn't it nevertheless strange that it still is noticable faster when using the SocketConnector?! And in particularly, obviously, on the second scenario windows/freebsd? (what about windows/linux?) Btw, this would probably be a 100 Mbps network, so that ~11.5 MBps basically is rather close to the theoretical limit (100/8=12.5, plus TCP/IP overhead)? It would be very interesting if one of you could repeat the tests using a setup where you couple those two machines together with a 1Gbps line, to see what it'd really max out at. Note that very many boxes these days have a 1Gbps network port, but still most office/home switches are 100Mbps: You could actually just "hotwire" the boxen together w/o using a hub/switch (use static ips). One should load the entire file into memory then, or else the disk will definately limit - and probably use a somewhat larger file too, or else it will go too fast to give reliable measurements. In a normal (not extremely-high-amount-of-users) environment, it seems like it would be smarter to still stick with the good'ol SocketConnector, rather than with the new'n'flash, obviously still not quite broken in SelectChannel stuff?

            People

            • Assignee:
              nik gonzalez
              Reporter:
              Yug
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: