tyrus
  1. tyrus
  2. TYRUS-188

[PERF] WebSocket client library creates too many threads per connection

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1
    • Component/s: None
    • Labels:
      None

      Description

      This issue is present in previous builds too.

      We have used WebSocket client API to write WebSocket performance benchmarks. We create tens of thousand of connection for the benchmark. Code looks like this,

      Session sessions = new Session[50000];
      ClientManager container = ClientManager.createClient();
      for (int i = 0 ; i < 50000; i++) {
      try

      { sessions[i] = container.connectToServer(new EchoWebSocketListener(), URI.create(uri)); sessions[i].setMaxIdleTimeout(-1); }

      catch (Exception e)

      { System.out.println("Exception thrown while opening connection number: " + i); e.printStackTrace(); }

      }

      Each call to container.connectToServer() creates plenty of threads (around 50 in number). They are Selector and Worker threads created internally by grizzly code. This hurts benchmark badly as for 50k connections there will be 2.5 million threads. We definitely want to avoid this.

      I have traced the problem to org.glassfish.tyrus.container.grizzly.GrizzlyClientSocket.java file.
      connect() method of GrizzlyClientSocket class builds/creates transport & starts it for each connection like this,

      transport = TCPNIOTransportBuilder.newInstance().build();
      transport.start();

      This internally creates lots of Selector & Worker threads depending upon number of processors present in the system. This should be avoided by creating transport object only once so that Selector & Worker threads will be shared among all the connections. For now, with my limited knowledge about Grizzly I have made temporary changes into our copy of GrizzlyClientSocket.java but we would like you to modify GrizzlyClientSocket.java appropriately and have it available to us in future versions.

        Activity

          People

          • Assignee:
            Pavel Bucek
            Reporter:
            amitagarwal
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: