What types of production problems should I expect when deploying a Flex application?

My company works on the Flex toolbar, which displays real-time financial information. It will be deployed over the corporate global network, perhaps several dozens of users.

This is our first Flex project, and although the development was very enjoyable, we are a little worried that there may be performance issues (users who do not have the appropriate Flash Player, long download times, BlazeDS performance, etc.),

Our stack is RDBMS / Spring / BlazeDS (Remote Messaging) / Flex.

Does anyone with experience implementing a commercial Flex application have any tips?

+4
source share
3 answers

Perhaps your biggest problems are:

  • Your users do not have the correct flash player version.
  • your users who have locked desktops, and either can not download the desired version of the player, or can not use the player at all
  • swf download speed if you have a big application
  • intermittent loss of connection to your server due to errors in the code or inaccessible network connection
  • browser restrictive policies

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

I assume that you tested your application for performance under a reasonable load and have already fixed these scalability issues :-)

NTN

+4
source

If you are talking about dozens of users, I don’t think that you will have many performance problems. In my opinion, the first bullets in the Simon tree will be the most likely problems. We have a flexible business solution with the .NET / WebORB backend and MS SQL2005 server.

The SWF application for the external interface is about 1.2 MB. If you have a broadband Internet connection, boot time is not a problem (since this is a corporate deployment on a WAN, I think this is not a problem). If not, then the first time the user loads swf, it will take some time, but then it should be cached. (Caching is another problem if you often have new builds. It is best to have a context menu in swf where you can see buildversion. If the user has problems with the application, one of the first things I check is , latest version.).

Sometimes a third-party player is simultaneously used by 500 candidates. Each player downloads and saves data on the server. So far, we have not had any problems, and I know that the use of the cache on the server side can be significantly increased. Stresstests are important here because a lot depends on your architecture, equipment, concurrent users, ...

We also use messaging for pessimistic concurrency management and this is a whole other story. We did a lot of testing here so that everything is fine and works well.

Security does not seem to be a big problem in your project, as it is being deployed corporate. But keep in mind that remote calls available to swf are not secure without security.

Lieven Cardoff aka Johlero

+2
source

our logs showed that flexible applications will accidentally delete connections to our servers. We have completed adding automatic retry logic to all of our REST calls.

+1
source

All Articles