3

Questions:

  • How do I get progress information to debug how long data takes to come over the wire when using a RemoteObject to load data from BlazeDS
  • How do investigate and speed up AMF message deserialization

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>
Roaders
  • 4,373
  • 8
  • 50
  • 71
  • It's hard to answer "why is this code slow" without seeing any code... – CyanAngel Jun 19 '14 at 08:50
  • Well, that wasn't the question was it. There is no code. This is the deserialisation of an AMF object that is handled under the covers by the framework. It is slow before it gets to any of the code I have written. – Roaders Jun 19 '14 at 08:57
  • It's pretty important to define how you get that data. Is it http or sockets, or what? What kind of framework do you use? – Andrey Popov Jun 19 '14 at 08:57
  • @Roaders then I'd suggest stating the question alittler clearer, because, to me that's how it appears. – CyanAngel Jun 19 '14 at 09:00
  • It's a RemoteObject talking to BlazeDS on a Java backend. I will edit the question a little bit to make it clearer what I am after. Thanks – Roaders Jun 19 '14 at 09:05
  • Again, you haven't provided information about framework do you use, so that everything's done before any code that you've written? – Andrey Popov Jun 19 '14 at 09:09
  • @AndreyPopov the framework I am using is Parsley but that has nothing to do with this. The message is deserialised before it reaches my code or Parsley. I have updated the question with Sample code that would replicate this slow load. – Roaders Jun 19 '14 at 09:17
  • That's why you should write your own protocol for communication :) Well the thing here is pretty simply - just use all the listeners that can be added to everything - the RemoteObject, the channel and the operation. They fire events when they do stuff, so you would be able to calculate the time using `getTimer` ;) – Andrey Popov Jun 19 '14 at 09:46
  • Generally I think AMF is pretty good - small messages and pretty quick. I've done a bit more investigation and my 6,000 objects is actually more like 5,000,000 if you count all the nested objects. The only way I could improve the processing is to split the processing over frames so the GUI doesn't lock up. I'll look into Operation and Channel events. – Roaders Jun 19 '14 at 09:50
  • @AndreyPopov - looked into ChannelSet and Operation. Neither seem to dispatch any progress related events. :-( – Roaders Jun 19 '14 at 10:03
  • There's no solution for your setup. Deserialization is a complex process that is out of your hand. For that amount of data the corresponding Object are created and that process takes time and idle your app. Like I said there's no solution with your setup so to fix it you'll have to change your setup. Options are (there might be more), streaming data, sockets, break data in pieces, etc. At the end the process should take as long as it takes now but your app won't idle. – BotMaster Jun 19 '14 at 20:11

1 Answers1

0

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.

Bolesław Chrobry
  • 184
  • 3