| Gabriel Dewitt 2006-06-08, 7:11 am |
| Greetings to One and All,
I am building a FMS app that is likely to have a large number of concurrent
users. These users will be moving around audio data (streaming into and out
of the FMS server). I have a dynamic balance I am trying to maintain between
the size of the Enterprise license I must buy to support my concurrent
connections and the time delay imposed on my users while I establish their
socket connection. I am looking to you, the best and brightest of the FMS
world, to help me determine which methodology to implement for socket
management (and as an aside if any of you have any good intel on licensing
options please let me know). Here are the methodologies that I am thinking
about today:
1. Minimize wait. As soon as the .swf file loads a socket connection is
created and maintained until the user either finishes working with the audio
data transfer part or leaves the page. This method means the most concurrent
sockets are created, but the least amount of time is spent waiting to
establish socket connections. Research indicates that each user could be
holding onto the socket connection for as long as 15 minutes on average...
2. Minimize concurrence. No socket connection is made until the user
actually tries to do something that requires a socket connection (such as
listening to a sound clip or recording their voice). And, each time the
stream is done the socket is closed. I have implemented a method such as
this before and it turned out to cause some problems around wait time as
sockets were opened and closed quite a bit. However, in the end it will
likely produce less concurrent connections than method #1.
3. First use. Socket connection is not made until the first time it is used
and then it is left open until the user is done. I would guess this would be
only a little more efficient than method #1 b/c the whole purpose of using
the application is the listen to and record audio - therefore the user will
likely request a socket connection fairly quickly and by opening a socket
connection as soon as the user gets to the page I am able to do some mean
average bandwidth profiling before they ask to use a stream.
4. Aggressive Timeout. Open the socket right away, but then close it after x
seconds of inactivity to save on concurrence. Not too many thoughts on this,
it seems reasonable to implement but I'm not sure how much it is going to
save. Still probably good to not have to hold a socket open for 20 minutes
while a user goes to the bathroom.
Other thoughts? One other method I've thought about but am not sure if is
doable is a sort of socket pool where the server maintains a pool of open
connections (is this possible?) but the clients wait until necessary to grab
one, thereby removing the wait for the socket connection. The server would
also manage the size of the pool based on load numbers coming from the web
server. If this is possible it seems like it could be the most efficient
method, but it also seems complicated.
So, anyone have thoughts on this? Any insights appreciated.
Thanks,
Gabriel
________________________________________
_______
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
|