Take a peek a http://www.tomlink.net and look for his
WebService / AMF comparison. You feed it the details of the request and
it times how long it takes to crunch through the data. It is a very cool
application.
BTW – if anyone on this list knows
Tom I would love to get an email for him.
Thanks,
Jeff
Founder
Flex Authority
http://www.flexauthority.com
We are actively seeking contributors for
the site. Have a sample that you want to share with the world? Send
it to us!
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Matt Chotin
Sent: Monday, June 13, 2005 4:29
PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Remoting
peformance for large lists
Have you ready my large data
articles? Probably explains what’s going on as far as
deserialization and whatnot (and potential approaches that may or may not be
applicable to charts).
http://www.markme.com/mchotin/archives/cat_data_management.cfm
down at the bottom.
Matt
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Alex Cruikshank
Sent: Monday, June 13, 2005 3:15
PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Remoting
peformance for large lists
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
