Macromedia Flash Server - Re: How do FMS2.01 measure bandwidht <> License

This is Interesting: Free IT Magazines  
Home > Archive > Macromedia Flash Server > April 2006 > Re: How do FMS2.01 measure bandwidht <> License





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 Re: How do FMS2.01 measure bandwidht <> License
ryanm

2006-04-27, 1:12 pm

> We have similar problems (also same kind of app, only with 4 cams, not 8).
> Also with 200 users it becomes very slow. Strange thing is that the
> bandwidth is not the issue since we have similar problems with different
> kinds of bandwidth usage (ranging from 35 - 50mbit). What we found out is
> that it has something to do with the number of incoming streams that needs
> to be send to the viewers (I don't know what FMS2 does internally with
> them).
>

You guys need to check your client-side for bottlenecks. I'm currently
running a chat server and we have up to 1000 concurrent users, each of whom
can publish a stream and consume up to 8 streams, and we have no performance
problems at all. In addition to that, we have 7500 or so users connecting to
the comm server from other places on the site (with no video), all on the
same FCS 1.5 server. We push right up to the edge of maxing out our 4
stacked FCS 1.5 licenses (10k concurrent conns), and so far server
performance hasn't even been a concern.

I mean, it does slow down a bit during peak traffic in busy rooms, but
we're talking about 5x as many users as what you're talking about. I found
that the biggest bottleneck in my chat on the client side was the user list.
Because people are constantly dropping in and out of chat rooms, the whole
list was being pushed out to every client *several times per second*, which
meant the chat client was in a constant state of redrawing. I made some
optimizations to how often the user list was updated and optimized the user
list object to only draw new users and leave users that are still on the
list after a refresh alone (no redraw), and I also put a buffer on the list
so that if it was currently in the middle of updating it didn't watch the SO
for updates, and the vast majority of my performance problems dissapeared.

Seriously, look at your client before you go spending money on the
server, because it is likely that your performance issues are there.

ryanm

________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com