tags:

views:

316

answers:

3

My company has been working on a Flex dashboard that displays realtime financial information. It will be deployed over a corporate WAN to perhaps a few dozen users.

This is our first Flex project, and while development has been very pleasant, we're a little concerned about what production issues might come up (users not having the right Flash player installed, long download times,BlazeDS performance, etc).

Our stack is RDBMS/Spring/BlazeDS (remoting and messaging)/Flex.

Does anyone with experience deploying a commercial Flex app have any words of advice?

+3  A: 

Your biggest problems are likely to be:

  • your users not having the correct version of the flash player
  • your users having locked-down desktops and either not being able to download the right version of the player or not being allowed to use the player at all
  • download speeds of the swf if you have a big app
  • intermittent loss of connection to your back-end due to either bugs in your code or unavailable network connection
  • restrictive browser policies

None of these are insurmountable, but you are likely to encounter all of them in the first few months.

I am presuming that you have tested your app for performance under reasonable load and will have fixed those scalability issues already :-)

HTH

Simon
+1  A: 

our logs showed that flex apps would randomly drop connections to our servers. We ended up adding automatic retry logic to all of our REST calls.

Brian
+2  A: 

If you're talking about a few dozen users I don't think you'll have a lot of performance issues. In my opinion the first tree bullets of Simon will be the most likely problems. We have a flex business solution with a .NET/WebORB backend and a MS SQL2005 server.

The swf of the frontend application is about 1.2 Mb big. If you have a broadband internet connection, then download time is not an issue (as it is corporately deployed in WAN, I guess this is no issue). If not, then the first time the user loads the swf it will take some time, but then it should be cached. (caching is another issue if you often have new builds. Best is to have a contextmenu in your swf where you can see the buildversion. If a user has problems with the application, one of the first things I check is whether they have laoded the last version.).

At times the frontend player is simultaneously used by 500 candidates. Each player loads and saves data regularely to the server. We have had no problems so far and I know that using cache on the server side performance can be increased a lot. Stresstests are important here as a lot depends on your architecture, hardware, concurrent users, ...

We also use messaging for pessimistic concurrency control and that's a whole other story. We have done a lot of testing here to get things up and running well.

Security doesn't seem a great issue in your project as it is deployed corporately. But be aware that remote calls available to the swf are not secured without security.

Lieven Cardoen aka Johlero

Lieven Cardoen