actionscript-3blazedsamf

How do I debug AMF performance issues in actionscript


Questions:

Background:

In my app we are loading around 6,000 rows of data which is very slow. Initially we all pointed fingers at the server guys and they have done quite a bit of work to speed this up. It's still slow though and at least some of it is due to the client.

As I said we have around 6,000 rows. These are large complex objects though which are deeply nested and have many lists of other complex objects inside them.

The load takes over 30 seconds. For the first 15 - 20 the spinner spins. For the last 15 or so seconds the UI locks up in a very ugly way so I suspect that it's taking 15 seconds to deserialise the AMF message. I am told that the AMF message is about 20 MB.

I suspected that my code that parses these rows might be to blame but that takes about 0.3 seconds.

Firstly I want to see how long it takes to get the first byte from the server, then see how long the transfer takes, then investigate if I can speed up the deserialisation.

There doesn't seem to be any way of getting progress events from a RemoteObject and there doesn't seem to be any way of looking into or optimising the deserialisation...

The Actionsctipt transfer classes are autogenerated by GAS on the server side build BTW so implementing IExternalisable is not an option.

I hope someone can help...

Sample Code To Reproduce:

<?xml version="1.0"?>
<s:WindowedApplication
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
creationComplete=" myRemoteObject.loadMyData() "
>

<fx:Declarations>

    <s:RemoteObject
        id="myRemoteObject"
        endpoint="myEndPoint"
        destination="myDestination"
        />

</fx:Declarations>

</s:WindowedApplication>

Solution

  • The AMF handling (including serializing/deserializing) is done by the NetConnection class, which is 'native' to the FlashPlayer, so it's practically impossible to debug. 20 MB of an AMF message is a lot, so it's going to take some time to fetch and deserialize it - none of these processes is optimizable, I think.

    I'd suggest sending the data in chunks and combining them on the client side. If every chunk contained 100 rows there would be 60 'spinner locks' each lasting quarter of a second. However the total load time would roughly be the same (could be even longer due to an overhead caused by doing multiple requests instead of one) and I don't see a way of making it faster other than using a different serialization method and/or altering data structures.