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

        Hide
        amitagarwal added a comment -

        Hi Dhiru,

        Please see who can address this. This is not very urgent but needs to be fixed.

        Amit.

        Show
        amitagarwal added a comment - Hi Dhiru, Please see who can address this. This is not very urgent but needs to be fixed. Amit.
        Hide
        Dhiru Pandey added a comment -

        Moving this issue to Tyrus project

        Show
        Dhiru Pandey added a comment - Moving this issue to Tyrus project
        Hide
        Pavel Bucek added a comment -

        fixed in the trunk

        Show
        Pavel Bucek added a comment - fixed in the trunk
        Hide
        amitagarwal added a comment -

        I have looked at the fix. Fix creates only two threads, one for Selector & another for Worker thread. This definitely is a better implementation than previous one but is not very elegant and does not solve our problem. If we create 50k or 100k connections for our benchmarks, this would create 100k or 200k threads resulting into huge overhead of thread context switching. We expect a better solution.

        Show
        amitagarwal added a comment - I have looked at the fix. Fix creates only two threads, one for Selector & another for Worker thread. This definitely is a better implementation than previous one but is not very elegant and does not solve our problem. If we create 50k or 100k connections for our benchmarks, this would create 100k or 200k threads resulting into huge overhead of thread context switching. We expect a better solution.
        Hide
        Pavel Bucek added a comment -

        Current change does guarantee same performance for all created clients; I don't want then to share any resources by default. There will be feature for setting custom Worked and Selector ThreadFactory.

        I can see what you want to do, but it is far from expected default behavior.

        Show
        Pavel Bucek added a comment - Current change does guarantee same performance for all created clients; I don't want then to share any resources by default. There will be feature for setting custom Worked and Selector ThreadFactory. I can see what you want to do, but it is far from expected default behavior.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: