3 Replies Latest reply on Apr 4, 2008 6:38 PM by Smeags

    Request consolidation

      We have been noticing severe performance problems in our Flex UI that seem to stem from the fact that Flex consolidates all requests over a given transport to one actual request to get around the 2 connection per browser limit.

      Our UI configures clients to two separate web service endpoints and performs a "hanging read" to each. The problem started appearing when we added the second hanging read. What happens is that other synchronous calls seem to be delayed until the next read is ready to go out, which occurs every 20 seconds. So ultimately, all other calls originating from the UI take 20 - n seconds to be sent.

      Is it actually true that Flex consolidates requests in this way? Does it matter that the two reads are against different endpoints?

        • 1. Re: Request consolidation
          ntsiii Level 3
          Sorry, not follwoing much of that. What is a "hanging read"? What are "..other synchronous calls ..." There are no synchronous data service calls in Flex.

          What RPC protocol are you using?

          • 2. Re: Request consolidation
            slaingod Level 1
            I've seen issues with having multiple ModuleLoader's run at once on start up (more than 2 and it randomly picks which ones actually run), so it certainly seems plausible there might be issues.

            I've heard people use multiple domains to get around the per domain connection limit in some scenarios (not for flash/flex, but in general). Ie. have your network people point regular.example.com and hanging.example.com to the same thing, and use the different domains to get around the limit.
            • 3. Re: Request consolidation
              Smeags Level 1
              This is all using web services (and the <mx:WebService> tag). A hanging read is similar to a poll except that the waiting occurs on the server side. For example, it might be configured to return after 20 seconds or if some event occurs, whichever comes first. The client then makes another call when the previous one returns, thus giving the same effect as a poll but providing more responsiveness (at the expense of keeping a connection alive for the life of the client).

              I experimented with this by separating out our two components, each with a hanging read as well as a set of other operations which can be called in a normal synchronous fashion. What I found was that "normal" calls seemed to get placed in some internal queue before actually being sent out. My evidence for this is that I observed a noticeable delay after calls to <operation>.send and before they arrived on the server. This delay seemed pegged to the timing of the hanging read going on in the background.

              This occurred in browsers with shared sessions (2 Firefox tabs, 2 IE Windows with the 2nd started with File->New Window). However, when I tested with two independent IE instances, it went away. My conclusion is that, behind the scenes, Flash is putting these requests on the same queue whenever they are part of the same HTTP Session. I'd love to hear from anyone else who has experienced this behavior.