Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next
    #1

    SmartGWT Power 6.1p Real-time messaging module

    Using Firefox 56 we are seeing very slow response times for GET calls to /messaging. For 250 subscribed channels it can take up to 2 minutes.

    We upgraded from 5.1p and do not see the same slowness as we are in 6.1p (nightly build 1/24/2018)

    Any ideas on what may have changed?
    Tags: None
    #2
    No one else has reported this. Let's first cover the basics:

    Is this Firefox-specific or reproducible with other browsers? Other platforms?

    Are you using JMS or the built-in (single-JVM) broker?

    If you switch to the single-JVM broker does the problem go away?

    Did you also upgrade or switch either your JMS provider (if applicable) or servlet engine at the same time?

    Have you done any kind of profiling - even just looking at the logs - to get a rough idea of where the time is being spent? For one, are you sure the server is even being contacted immediately (a proxy or similar might cause this delay)?

    Comment

      #3
      We only compile against Firefox.

      We are not using JMS.

      This was only after upgrading from 5.1p to 6.1p.

      We've looked at Tomcat logs and isc.showConsole() logs all of which look normal. Is there a specific log/level that could shed some light?

      We believe the server is contacted because initial calls to GET /DataSourceLoader are successful and quick. Firefox web toolbar only indicates GET /messaging calls to take long.

      Comment

        #4
        Unless your application is non-functional in all other browsers, it's worth testing whether the problem is the same.

        As far as determining what's taking time, Firefox's "Network" developer tool can show the phases of the connection and data transfer - just hover over the multicolored bar in the timeline area.

        Comment

          #5
          In terms of logging, you can set the com.isomorphic.messaging category in WEB-INF/classes/log4.isc.config.xml to DEBUG and then ALSO set the "Messaging" category in the client-side Developer Console to DEBUG. This will produce additional timestamped output to review.

          A few more things that might explain a slowdown:

          In 6.1, Messaging was modified to reduce the possibility of dropping messages by overlapping a connection re-establishment. This means that when connections cycle over (controlled by messaging.connectionTTL in server.properties, and defaults to 2 minutes) more server resources are used and if the server is resource starved, then you can see latency on the client.

          Additionally, the recent Spectre and Meltdown security patches can halve the performance of the server or client, depending on workload. This is especially true of cloud servers where providers really have no choice but to apply the patch.

          Are you seeing the problem specific to Firefox 56? Is Firefox 55 working fine against both 6.1 and 5.1?

          Comment

            #6
            I commented out the Messaging.subscribe calls on the client and was still seeing the slowness.

            It appears to be completely on the client-side when it is loading a particular page in our application which contains alot of widgets (popups, forms and listgrids, but nothing out of the ordinary). The GET /messaging requests show up in the Network console as taking long, but I believe it is just backed up waiting for the client-side to finish loading.

            We've seen it in browsers as old as FF26 up to FF58.

            Any specific client-side logs that could help?

            Comment

              #7
              We do not see the slowness on version 6.0p (1/19/2018).

              Comment

              Previous template Next
              Working...
              X