|
Home > Archive > Macromedia Flash Server > April 2005 > Bandwidth Bottlenecks
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bandwidth Bottlenecks
|
|
| JesterXL 2005-04-07, 5:57 pm |
| Curious what are bandwidth bottlenecks? Playing with a small Flex +
Flashcom app, and my bandwidth for just 2 days of playing & developing was
78megs... holy cheese!
My guesses are here:
- RemoteShared objects
- NetConnection.call's
- unused NetStreams (for AudioConference which remains idle)
Anymore, and any quick suggestions on how to optimize your bandwidth for
data-esque applications ( I have no video).
Thanks if you can help!
--JesterXL
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bill Sanders 2005-04-07, 5:57 pm |
| Jesse,
I've been struggling with a similar dilemma for the last couple of
weeks. Mostly tips from Brian's books, but one I employed quickly is
not using onMouseMove w/ a shared objects. The material on dead
reckoning suggests some very nice algorithms that predict a direction
of movement, and they may be what you need.
Also, I've found that even more than BW, my processor is maxing out on
RSOs.
HTH,
Bill
On Apr 3, 2005, at 4:22 PM, JesterXL wrote:
> Curious what are bandwidth bottlenecks? Playing with a small Flex +
> Flashcom app, and my bandwidth for just 2 days of playing & developing
> was
> 78megs... holy cheese!
>
> My guesses are here:
>
> - RemoteShared objects
> - NetConnection.call's
> - unused NetStreams (for AudioConference which remains idle)
>
> Anymore, and any quick suggestions on how to optimize your bandwidth
> for
> data-esque applications ( I have no video).
>
> Thanks if you can help!
>
> --JesterXL
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-04-07, 5:57 pm |
| I second that, look at the SO's more closely. I doubt that idle NetStreams
would take up much bandwidth, if any.
Got some more info on what the app is doing?
Stefan
[vbcol=seagreen]
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Bill Sanders
> Sent: 03 April 2005 21:44
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] Bandwidth Bottlenecks
>
> Jesse,
>
> I've been struggling with a similar dilemma for the last
> couple of weeks. Mostly tips from Brian's books, but one I
> employed quickly is not using onMouseMove w/ a shared
> objects. The material on dead reckoning suggests some very
> nice algorithms that predict a direction of movement, and
> they may be what you need.
>
> Also, I've found that even more than BW, my processor is
> maxing out on RSOs.
>
> HTH,
> Bill
>
> On Apr 3, 2005, at 4:22 PM, JesterXL wrote:
>
> small Flex +
> developing
> bandwidth
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| JesterXL 2005-04-07, 5:57 pm |
| Sure, it's an improved version of my D&D components. Basically, chat is
sending about 100 character chat messages via nc.send, I have some dice roll
information being sent (a small generic object) about every 2 minutes, and
some 20 character action messages being sent.
I can upload a fresh Flex build tomorrow morning for you all to check it
out... I'll build a profilier in in the meantime, although, I doubt how
useful it'll be.
----- Original Message -----
From: "Stefan Richter" <stefan-fMeCE+ULXElEfu+5ix1nRw@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, April 04, 2005 4:07 AM
Subject: RE: [FlashComm] Bandwidth Bottlenecks
> I second that, look at the SO's more closely. I doubt that idle NetStreams
> would take up much bandwidth, if any.
> Got some more info on what the app is doing?
>
> Stefan
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Jim Cheng 2005-04-07, 5:57 pm |
| JesterXL wrote:
> Curious what are bandwidth bottlenecks? Playing with a small Flex +
> Flashcom app, and my bandwidth for just 2 days of playing & developing was
> 78megs... holy cheese!
>
> My guesses are here:
>
> - RemoteShared objects
> - NetConnection.call's
> - unused NetStreams (for AudioConference which remains idle)
>
> Anymore, and any quick suggestions on how to optimize your bandwidth for
> data-esque applications ( I have no video).
One of the worst bandwidth hogs I've discovered so far is binding a data
provider inside a remoted shared object to either a V2 List Component or
a subclass of it. This unfortunately causes the shared object to be
continually updated via the onSync event as a result of contention over
the __ID__ preoperty. Invariably, this consumes significant bandwidth
and available processor cycles.
If this sounds like something you might be doing, you might want to
check how often your onSync event handler is getting fired. In one
project I worked on, this very problem yielded significantly degraded
performance and painfully, wasn't caught for over a month until I had
serendipitously added a trace to the shared object's onSync event handler.
A quick workaround is to simply to make a clone (e.g. copy by value) of
the data provider object from the shared object and use that instead for
your component's data provider. You can also prepopulate the __ID__
property with unique values of your own on ther server-side.
Brian Lesser and friends discuss various workarounds for this issue in
Programming Flash Communication Server (p. 631-633).
Jim
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| JesterXL 2005-04-07, 5:57 pm |
| I always make a clone so that isn't it... which sux, because I was hoping
there was an easier answer.
----- Original Message -----
From: "Jim Cheng" <jim-/KmwPUWnfB5YDkOOrDPCWw@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, April 04, 2005 3:07 PM
Subject: Re: [FlashComm] Bandwidth Bottlenecks
JesterXL wrote:
> Curious what are bandwidth bottlenecks? Playing with a small Flex +
> Flashcom app, and my bandwidth for just 2 days of playing & developing was
> 78megs... holy cheese!
>
> My guesses are here:
>
> - RemoteShared objects
> - NetConnection.call's
> - unused NetStreams (for AudioConference which remains idle)
>
> Anymore, and any quick suggestions on how to optimize your bandwidth for
> data-esque applications ( I have no video).
One of the worst bandwidth hogs I've discovered so far is binding a data
provider inside a remoted shared object to either a V2 List Component or
a subclass of it. This unfortunately causes the shared object to be
continually updated via the onSync event as a result of contention over
the __ID__ preoperty. Invariably, this consumes significant bandwidth
and available processor cycles.
If this sounds like something you might be doing, you might want to
check how often your onSync event handler is getting fired. In one
project I worked on, this very problem yielded significantly degraded
performance and painfully, wasn't caught for over a month until I had
serendipitously added a trace to the shared object's onSync event handler.
A quick workaround is to simply to make a clone (e.g. copy by value) of
the data provider object from the shared object and use that instead for
your component's data provider. You can also prepopulate the __ID__
property with unique values of your own on ther server-side.
Brian Lesser and friends discuss various workarounds for this issue in
Programming Flash Communication Server (p. 631-633).
Jim
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Brian Lesser 2005-04-07, 5:57 pm |
| Hi Jesse,
Off the top of my head the only thing I can suggest you check is if you
are frequently updating arrays or objects within shared object slots. If
you are, then you may want to redesign what you store in a slot. For
example if you have a user object in an SO like this:
users_so.data.jester = {
firstName: "Jesse",
lastName: "Warden",
nickName: "JesterXL",
arrival: new Date(),
status: "online"
}
and then you keep changing the status value:
users_so.data.jester.status = "busy";
Each time you do that the entire contents of the slot is copied to every
client connected to the shared object. So even if that is only 120 bytes
per object you have to multiply that plus some version info times each
client times each time you change one property. So, often to optimize
things you have to break shared objects apart:
users_so.data.jester = {
firstName: "Jesse",
lastName: "Warden",
nickName: "JesterXL",
arrival: new Date()
}
status_so.data.jester = "online";
With games or just moving around avatars it is really important to
optimize things so you only send the information that really needs to be
sent. If very frequent updates must occur you can replace strings with
one byte characters or with numbers:
status_so.data.jester = 1;
But then you probably know all that already... Sorry if it doesn't help.
Yours truly,
-Brian
JesterXL wrote:
[vbcol=seagreen]
>I always make a clone so that isn't it... which sux, because I was hoping
>there was an easier answer.
>
>
>----- Original Message -----
>From: "Jim Cheng" <jim-/KmwPUWnfB5YDkOOrDPCWw@public.gmane.org>
>To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
>Sent: Monday, April 04, 2005 3:07 PM
>Subject: Re: [FlashComm] Bandwidth Bottlenecks
>
>
>JesterXL wrote:
>
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| JesterXL 2005-04-07, 5:57 pm |
| It's not that I didn't know it, but rather didn't care. All this
optimization Sam Wan used to spout I took as hogwash... who cares? I
figured since we're all on the AMF-binary packet ride to the server, we're
all happy right?
Wrong. I was wrong in thinking that Flash would do the optimization work
for me, and your math below proves that; I never even took that into
account, let alone counted.
Good thing, though, is to me, re-factoring SO data structures is cake. I
bet you your right and that's the main one. I'm aprehensive on doing it,
yet, because I want to have a way to prove it worked once implemented.
----- Original Message -----
From: "Brian Lesser" <blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, April 04, 2005 6:22 PM
Subject: Re: [FlashComm] Bandwidth Bottlenecks
Hi Jesse,
Off the top of my head the only thing I can suggest you check is if you
are frequently updating arrays or objects within shared object slots. If
you are, then you may want to redesign what you store in a slot. For
example if you have a user object in an SO like this:
users_so.data.jester = {
firstName: "Jesse",
lastName: "Warden",
nickName: "JesterXL",
arrival: new Date(),
status: "online"
}
and then you keep changing the status value:
users_so.data.jester.status = "busy";
Each time you do that the entire contents of the slot is copied to every
client connected to the shared object. So even if that is only 120 bytes
per object you have to multiply that plus some version info times each
client times each time you change one property. So, often to optimize
things you have to break shared objects apart:
users_so.data.jester = {
firstName: "Jesse",
lastName: "Warden",
nickName: "JesterXL",
arrival: new Date()
}
status_so.data.jester = "online";
With games or just moving around avatars it is really important to
optimize things so you only send the information that really needs to be
sent. If very frequent updates must occur you can replace strings with
one byte characters or with numbers:
status_so.data.jester = 1;
But then you probably know all that already... Sorry if it doesn't help.
Yours truly,
-Brian
JesterXL wrote:
[vbcol=seagreen]
>I always make a clone so that isn't it... which sux, because I was hoping
>there was an easier answer.
>
>
>----- Original Message -----
>From: "Jim Cheng" <jim-/KmwPUWnfB5YDkOOrDPCWw@public.gmane.org>
>To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
>Sent: Monday, April 04, 2005 3:07 PM
>Subject: Re: [FlashComm] Bandwidth Bottlenecks
>
>
>JesterXL wrote:
>
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bob Wohl 2005-04-07, 5:57 pm |
| I've noticed the CPU issue as well with RSOs.
Does Brian's book have any info on making the RSOs less CPU intensive? I
cant seem to come up with a way to do it. Is it just a hang on the info and
causing client side to choke on it?
Bob
----- Original Message -----
From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Sunday, April 03, 2005 1:44 PM
Subject: Re: [FlashComm] Bandwidth Bottlenecks
> Jesse,
>
> I've been struggling with a similar dilemma for the last couple of
> weeks. Mostly tips from Brian's books, but one I employed quickly is
> not using onMouseMove w/ a shared objects. The material on dead
> reckoning suggests some very nice algorithms that predict a direction
> of movement, and they may be what you need.
>
> Also, I've found that even more than BW, my processor is maxing out on
> RSOs.
>
> HTH,
> Bill
>
> On Apr 3, 2005, at 4:22 PM, JesterXL wrote:
>
> bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> __________ NOD32 1.948 (20041214) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.nod32.com
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Brian Lesser 2005-04-07, 5:57 pm |
| Hi Bob,
In my experience well thought out sets of RSOs aren't that CPU
intensive. However, I have found that updating the UI Components can
suck the life out of your Flash movie if you're not careful. I never use
List or DataGrid methods like addItem() anymore. I always grab the List
or Grid's dataprovider, clear and repopulate it, and then have the
dataprovider notify the List or Grid to redraw itself only once. So, if
your app is slow on the client, you have a lot of data in your SOs, and
you display the data in a List or Grid, that could be a factor. The
first part of chapter 15 goes through all that in brutal detail.
Yours truly,
-Brian
Bob Wohl wrote:
[vbcol=seagreen]
>I've noticed the CPU issue as well with RSOs.
>
>Does Brian's book have any info on making the RSOs less CPU intensive? I
>cant seem to come up with a way to do it. Is it just a hang on the info and
>causing client side to choke on it?
>
>
>Bob
>----- Original Message -----
>From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
>To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
>Sent: Sunday, April 03, 2005 1:44 PM
>Subject: Re: [FlashComm] Bandwidth Bottlenecks
>
>
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bill Sanders 2005-04-07, 5:57 pm |
| Brian,
I found that using an RSO to open a web page spikes my CPU, and since
it doesn't use anything more than a Boolean and a string (to pass the
name of the Web page) and uses no components, why would that have such
an effect on the CPU?
(Brutal detail is right....)
TIA,
Bill
On Apr 4, 2005, at 8:57 PM, Brian Lesser wrote:
> Hi Bob,
> In my experience well thought out sets of RSOs aren't that CPU
> intensive. However, I have found that updating the UI Components can
> suck the life out of your Flash movie if you're not careful. I never
> use List or DataGrid methods like addItem() anymore. I always grab the
> List or Grid's dataprovider, clear and repopulate it, and then have
> the dataprovider notify the List or Grid to redraw itself only once.
> So, if your app is slow on the client, you have a lot of data in your
> SOs, and you display the data in a List or Grid, that could be a
> factor. The first part of chapter 15 goes through all that in brutal
> detail.
> Yours truly,
> -Brian
>
> Bob Wohl wrote:
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Brian Lesser 2005-04-07, 5:57 pm |
| Hi Bill,
From what you wrote, I doubt that has anything to do with the RSO. It's
more likely the cost of starting up another browser window and loading
its contents...
Cheers,
-B
Bill Sanders wrote:
> Brian,
>
> I found that using an RSO to open a web page spikes my CPU, and since
> it doesn't use anything more than a Boolean and a string (to pass the
> name of the Web page) and uses no components, why would that have such
> an effect on the CPU?
>
> (Brutal detail is right....)
>
> TIA,
> Bill
>
> On Apr 4, 2005, at 8:57 PM, Brian Lesser wrote:
>
> bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bob Wohl 2005-04-07, 5:57 pm |
| Yeah, I've seen a hit on some apps with UI components. Only one that has
been in use as of late has been the people list component. Not Sure if that
one is cuasing any of the issues with CPU. As for the use of RSOs, I have a
number of them that only maintain 1 - 5 vars. Granted it's a large app with
a ton of functions and a ton of RSOs, I've parted out the RSOs so that only
1 var will change to only one RSO at a time. Most are numeric values (like 1
for true, 2 for false etc.). Others like text notes, questions are strings
of course.
I guess I will go track down your book. It's been a while since I've heard
anything on it(released or not) till the other day/week when some one
mentioned it was not on amazon. People keep quoting out of it like it's the
bible, so it must be good ;)
Thanks,
Bob
----- Original Message -----
From: "Brian Lesser" <blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, April 04, 2005 5:57 PM
Subject: Re: [FlashComm] Bandwidth Bottlenecks
> Hi Bob,
> In my experience well thought out sets of RSOs aren't that CPU
> intensive. However, I have found that updating the UI Components can
> suck the life out of your Flash movie if you're not careful. I never use
> List or DataGrid methods like addItem() anymore. I always grab the List
> or Grid's dataprovider, clear and repopulate it, and then have the
> dataprovider notify the List or Grid to redraw itself only once. So, if
> your app is slow on the client, you have a lot of data in your SOs, and
> you display the data in a List or Grid, that could be a factor. The
> first part of chapter 15 goes through all that in brutal detail.
> Yours truly,
> -Brian
>
> Bob Wohl wrote:
>
and[vbcol=seagreen]
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> __________ NOD32 1.948 (20041214) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.nod32.com
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|
|
|
|
|