|
Ted:
How many concurrent users can FDS
Express support?
On the departmental version, if the 101st concurrent user
tries to connect is there an
error message or busy message or do they just wait a little
longer to get the data?
Thanks,
Jack From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Patrick Sent: Thursday, August 24, 2006 1:57 PM To: [email protected] Subject: RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides
FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE FDS Express == 1CPU
FREE - FDS Express is limited to one 1
physical CPU (multi-core supported) - FDS Express cannot be clustered
for failover and redundancy. All higher level FDS Licenses
address the redundancy and failover aspects for departmental use (100 concurrent
users) and enterprise (unlimited users). The blanket statement that FDS
costs $20,000 is dead wrong. For a large majority of projects it is free, free,
free. Ted
Patrick Flex
Evangelist Adobe Systems
Incorporated From:
I have to
agree with Ted regarding productivity. On 8/23/06, AMF is faster in 3 fundamental
ways:
Web Services are dependent on XML
Parsing on both the client and server side. Although it's a good story, XML
parsers are not very efficient as parsing documents is an interpreted process.
The Flash Player XML parser will always be dramatically slower than AMF parsing,
binary formats are notoriously faster in this regard. XML parsing additionally decays
rapidly as the file size increases. Flash Player XML parsing time increase
non-linearly with larger XML documents. With AMF parsing times are linear with
data size. The XML decay can be attributed to the number of inner objects that
need to be created during a parsing run. AMF objects are 1:1 with the data
received where XML data is 1:N per Elements/Attribute. Comparing XML to AMF is an unfair
race, AMF wins every time. When you add in the overhead of WS SOAP parsing atop
the base XML parser speed you begin to see performance issues. With SOAP, you
interpret an XML document back into typed objects depending on the SOAP
specifics used. Sure 350ms is ok once or twice, but try doing 200 transactions
in this format and you will see performance issues arise. Using Web Services you
are forcing the Flash Player to do allot of unneeded work. The goal is to build
richer applications, not burn up player performance in crud
operations. Additionally non-proxied Web
Service use suffers with Flash Player because of the browser variation in the
plug-in APIS. You cannot get the 500 Errors response content in IE and thus the
SOAP fault standard breaks down. In SOAP there are important messages that
arrive with 500 Errors and the inability of the Flash Player to receive these is
a problem. Unfortunately there is no seamless way to get 500 Errors into the
Flash Player other then rewriting an HTTP Client in the Socket class. This
effort would also require a new SOAP library within Flex and socket use on low
ports requires a more complex crossdomain. Performance aside, the
productivity discussion is much more important. AMF3 and Flex Data Services are
wildly productive. Once you compile your Java Class and configure a destination
in FDS (1 XML Element), you are done. All typing is handled, All methods are
ready to run with any number of client applications. It is the easiest way to
create a server side API that I know of. Actually most cases, implementing FDS
will removes $20,000 of developer time wasted on implementing other data
exchange for an application. FDS value is easy to see when viewed through this
productivity ROI metric. If you add CF integration into FDS, you enjoy an even
more productive jump. We spend so much time talking about performance but we
often waste so much developer time doing mundane data exchange when things could
be automated. Having worked at Cynergy Systems,
everyone needs to realize that Carson, Dave and Team are industry leading
professionals at Web Services. They know SOAP better than any single consulting
firm that I know of. These guys were on teams at Sybase and Microsoft building
the first generation of Web Services integration servers (MS BizTalk,
EAServer)!!! They have the expertise to make Web Services/JAVA work seamlessly
with Flex but this is out of reach for most (unless you hire them). They can
jump through flaming hoops that few developers can with the FLEX / TOMCAT / AXIS
/ JAVA stack. They have been down a very hard road and have learning all the
tricks to making this stack work very well for their clients. Looking back and
knowing what I know now about Flex Data Services much of this hard work could
have been dramatically simplified and automated (but then again Flex 2/FDS
hadn't shipped yet…). FDS makes all this hard work evaporate and makes easy for
anyone to exchange data like an industry leading
professional. The really funny part is that we
are only talking about the RPC portions of Flex Data Services. Messaging and
Data Management are really valuable features to understand and explore. These
two features are 70% of the FDS product. We(Adobe) need to do a better job of
making this value crystal clear. Flex Data Services is the most
productive and high performance way to exchange data with the Flash Player.
Period, Hands Down, Next! My 2
cents, Flex
Evangelist Adobe Systems
Incorporated -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___ |
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Ted Patrick
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Tom Lee
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Douglas Knudsen
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... ryanm
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... ryanm
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Tom Lee
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... ryanm
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Ted Patrick
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Jack Caldwell
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Jack Caldwell
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Michael Schmalle
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Bjorn Schultheiss
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... hank williams
- RE: [Junk E-Mail - LOW] Re: [Junk E-Mail - LOW] [flexcod... Shannon Hicks
- Re: [Junk E-Mail - LOW] Re: [Junk E-Mail - LOW] [flexcod... hank williams
- RE: [Junk E-Mail - LOW] Re: [Junk E-Mail - LOW] [flexcod... Bjorn Schultheiss

