RichFaces
  1. RichFaces
  2. RF-11156

a4j:push Performance problem in CDI sample of push in showcase

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Critical Critical
    • Resolution: Partially Completed
    • Affects Version/s: 4.1.0.Milestone1
    • Fix Version/s: 4.1.0.Milestone3
    • Component/s: examples
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Environment:
      richfaces-showcase 4.1.0-Snapshot, containers - JBoss AS 6 and 7
    • Similar Issues:
      Show 10 results 

      Description

      When there is more than 5 consumers windows, it causes performance problems(take up to 20 seconds to render message on consumer), at least from the beginning, after some messsages like 3-4 the performance is improved on AS 7.

        Activity

        Hide
        Juraj Húska
        added a comment -

        Some performance tips I have found:

        • Start the consumer before you start the producer so that the initial messages do not need to queue.
        • Use a ConnectionConsumer to process messages concurrently with a ServerSessionPool.
        • Close resources (e.g. connections, session objects, producers, consumers) when finished with them.
        • DUPS_OK_ACKNOWLEDGE and AUTO_ACKNOWLEDGE perform better than CLIENT_ACKNOWLEDGE.
        • Use separate transactional sessions and non-transactional sessions for transactional and non-transactional messages.
        • Tune the Destination parameters: a smaller capacity increases message throughput; a higher redelivery delay and lower redelivery limit reduces the overhead.
        • Choose non-durable (NON_PERSISTENT) messages wherever appropriate to avoid the persistency overhead.
        • Set the TimeToLive value as low as feasible (default is for messages to never expire).
        • Receive messages asynchronously with a MessageListener implementation.
        • Choose the message type that minimizes memory overheads.
        • Use 'transient' variables to reduce serialization overheads.
        Show
        Juraj Húska
        added a comment - Some performance tips I have found: Start the consumer before you start the producer so that the initial messages do not need to queue. Use a ConnectionConsumer to process messages concurrently with a ServerSessionPool. Close resources (e.g. connections, session objects, producers, consumers) when finished with them. DUPS_OK_ACKNOWLEDGE and AUTO_ACKNOWLEDGE perform better than CLIENT_ACKNOWLEDGE. Use separate transactional sessions and non-transactional sessions for transactional and non-transactional messages. Tune the Destination parameters: a smaller capacity increases message throughput; a higher redelivery delay and lower redelivery limit reduces the overhead. Choose non-durable (NON_PERSISTENT) messages wherever appropriate to avoid the persistency overhead. Set the TimeToLive value as low as feasible (default is for messages to never expire). Receive messages asynchronously with a MessageListener implementation. Choose the message type that minimizes memory overheads. Use 'transient' variables to reduce serialization overheads.
        Hide
        Lukáš Fryč
        added a comment -

        I can reproduce this issue.

        Initially I have verified that the performance does not affect all user sessions but only the session which has created more than ~5 consumer windows.

        Show
        Lukáš Fryč
        added a comment - I can reproduce this issue. Initially I have verified that the performance does not affect all user sessions but only the session which has created more than ~5 consumer windows.
        Hide
        Lukáš Fryč
        added a comment -

        We are reaching maximum number of opened HTTP connections per session, I will limit number of opened windows to 5.

        Show
        Lukáš Fryč
        added a comment - We are reaching maximum number of opened HTTP connections per session, I will limit number of opened windows to 5.
        Hide
        Juraj Húska
        added a comment - - edited

        The performance on Chrome after setting the maximum of consumers windows on 5 was improved, however when using Firefox 3.x, 5.x, 6.x, 7.x the performance is again very bad, when some of the consumer is replaced with new consumer, then the sent message is shown on consumer after 20 sec.

        Show
        Juraj Húska
        added a comment - - edited The performance on Chrome after setting the maximum of consumers windows on 5 was improved , however when using Firefox 3.x, 5.x, 6.x, 7.x the performance is again very bad , when some of the consumer is replaced with new consumer, then the sent message is shown on consumer after 20 sec.
        Hide
        Lukáš Fryč
        added a comment -

        I assume the behavior which is Jura experiencing is caused by number of connections opened to server and server/browser connection is not closed right after aborting XHR long-polling request.

        The behavior is though not real world scenario and users can toggle the number of connections in application server configuration if needed.

        We can't generally change number of concurrent connections per session in Showcase example, so closing this issue as partially completed.

        Note that this affects only particular browsers and it is nothing we can do about.

        Show
        Lukáš Fryč
        added a comment - I assume the behavior which is Jura experiencing is caused by number of connections opened to server and server/browser connection is not closed right after aborting XHR long-polling request. The behavior is though not real world scenario and users can toggle the number of connections in application server configuration if needed. We can't generally change number of concurrent connections per session in Showcase example, so closing this issue as partially completed. Note that this affects only particular browsers and it is nothing we can do about.

          People

          • Assignee:
            Lukáš Fryč
            Reporter:
            Juraj Húska
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: