Hi all, We're having some peformance problems on the client side when loading large lists of object graphs through our remoting inteface. I've written a simple test case to characterize the problem (the mxml file and remote object are attached), and I'm seeing some behavior I can't explain. I would appreciate any help anyone can provide understanding the problem or providing work-arounds.
The time between the remote method call and the resultHandler of the
call grows linearly with list size and/or object size as you'd expect.
We're also seeing a period of time after the result handler where the
application becomes unresponsive. This is what I can't explain. This
mystery time increases non-linearly with item count and seems to
increase greatly when items in the list reference other objects (even
if they all reference the same instance). I've traced data from
within the result in the resultHandler, so the action script objects
seem to be fully serialized by the resultHandler, so the clients
peformance after the resultHandler doesn't seem to be directly
hampered by object loading or creation.
The attached graphs show the results of my tests. In each graph the
time until the result handler is in orange, the time after the result
handler is green and the sum of the two is blue.
TOP LEFT: Load time per item where each item contains a map with 5
entries. Note that the mystery time (green) increases non-linearly,
and (excluding the spikes) the orange increase linearly.
TOP RIGHT: Load time per item, 10 entries. The orange lines slope
increases as you'd expect since the size of the objects have increased
by ~80%. The green line is identical to the graph of items with 5
entries.
MIDDLELEFT: Load time per item, 20 entries. Again the orange line's
slope increases as expected. The mystery time remains the same.
MIDDLE RIGHT: I modified the remoting code to create a single parent
item and give each item in the list a reference to it. I then created
a second parent object so that each object would have a reference to 2
parent objects (but only a single instance of each). I overlayed the
graphs so that the scales matched (each item had 10 map entries and
the bottom lines are test graphed in the TOP RIGHT). Note that adding
the one reference increases the mystery time by nearly 100% and adding
the second reference increases it by 150%.
BOTTOM LEFT: Load time per map item, 1000 items. Holding the items
constant, you can see that the mystery time holds constant after a
certain point, and the load time (orange) increases linearly with
object size as expected.
BOTTOM RIGHT: Repeated calls for 0 items. This is a control to
eliminate the possiblity that multiple calls or the graphing was
responsible for the slowdown.
Thanks,
Alex
Carbon Five
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
<<attachment: remote_performance.gif>>
testRemoteObjectTiming.mxml
Description: Binary data
TestRemote.java
Description: Binary data
