Month: January 2017

Debugging BlazeDS Performance

raindropsonrosebud I have a server call that returns a lot of data to the client.  About 80% of the elapsed time for the call is the time after the data leaves the server and before it arrives at the client.

We’re using BlazeDS to communicate between a Flex client and a Java back end.

It is crazy hard to find much information on performance tuning for BlazeDS.  But these two blog posts helped me figure out how to get some statistics about the messaging between server and client – things like elapsed time, size of message, etc.

So basically what you do is, on the server side in your services-config.xml file, in the tag of your tag, you add these two tags:


Then on the client side, when you instantiate a new AMFChannel, you add a line like this:


And add a new function called customSettings which sets the values for these same properties on the client-side.

 private function customSettings():XML {
 return <channel-definition>

Doing it this way gets around the problem of them being read-only properties.

Now, upon successful completion of service calls, add this code to your result handler:

log.debug(getResource(msg, destination, operationName, elapsedTime)); var performanceDetails:MessagePerformanceUtils = new MessagePerformanceUtils(event.message); log.debug(performanceDetails.prettyPrint());

More information on MessagePerformanceUtils here:

What this does is get you a bunch of information to help with figuring out why the call is taking so long.

Original message size(B): 1685
Response message size(B): 6987918
Total time (s): 8.402
Network Roundtrip time (s): 3.584
Server processing time (s): 4.818
Server adapter time (s): 3.708
Server non-adapter time (s): 1.11

Don’t leave this in your production code.  You’re trying to improve performance, not make it worse!