glassfish
  1. glassfish
  2. GLASSFISH-19067

[Perf] Glassfish performance drops when Fixed HTTP thread pool has much more threads in pool than number of clients

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b49
    • Fix Version/s: 4.0_b60
    • Component/s: grizzly-kernel
    • Labels:
      None
    • Environment:

      Linux 2.6.16.46 x86_64

      Description

      When running a JSP atomic benchmark accessing a simple JSP which creates and maintains a session with hit counter, we found that when http thread pool is configured much larger than number of users accessing it, Glassfish performance drops. The atomic test is run with 5 concurrent users without any think time. Keeping the concurrent users same, as size of thread pool is increased (i.e thread pool min & max values are changed), the performance metric transactions/sec (TPS) obtained from a test is less than that obtained earlier.

      Thread pool size TPS
      Min Max
      50 50 17368 (10x more threads)
      25 25 17799 (5x more threads)
      15 15 19669 (3x more threads)
      10 10 22527 (2x more threads)
      5 5 23384 (1x threads)

        Activity

        Hide
        deep_singh added a comment -

        Alexey has asked to try out latest Grizzly 2.3-SNAPSHOT since he has made some changes in Fixed Thread Pool. Following is a snippet from Alexey's email:

        "2.3-SNAPSHOT has all the perf. optimizations we applied recently. IMO the most important was to change BlockingQueue implementation in the FixedThreadPool: LinkedTransferQueue -> LinkedBlockingQueue. IMO it was the main source of the scalability problem. W/ LinkedTransferQueue in place Selector threads were spinning too much and consumed much more CPU than needed."

        Show
        deep_singh added a comment - Alexey has asked to try out latest Grizzly 2.3-SNAPSHOT since he has made some changes in Fixed Thread Pool. Following is a snippet from Alexey's email: "2.3-SNAPSHOT has all the perf. optimizations we applied recently. IMO the most important was to change BlockingQueue implementation in the FixedThreadPool: LinkedTransferQueue -> LinkedBlockingQueue. IMO it was the main source of the scalability problem. W/ LinkedTransferQueue in place Selector threads were spinning too much and consumed much more CPU than needed."
        Hide
        oleksiys added a comment -

        fixed

        Show
        oleksiys added a comment - fixed

          People

          • Assignee:
            oleksiys
            Reporter:
            deep_singh
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: