I’ve joined a project recently where I’ve been at the Macromedia office in San Francisco but the server I’ve been hitting is across the country. As soon as I started working I saw real performance problems where the application wouldn’t start for a long time. It turned out that there was a lot of data required for the app to initialize, but now that the data had to travel outside of the intranet its size became noticeable. This required a real adjustment for the application. The engineer decided to pass down thin versions of each object and as necessary load the additional details instead of getting all of the data at once . This reduced the amount of data on the wire significantly and allowed the app to start up in a reasonable time. Getting more data on demand produces a slight delay, but you can “entertain” the user easily enough to pass the time.
Another thing that we saw is that a RemoteObject call that had been working for the developers across the country was not working for me. It turned out that we had concurrency set to single for a method on one of our RemoteObjects. For the developers working locally the first call to this method was returning in time for the second call to succeed. But when working from a distance the second call would fault because the first call had not completed. Add in the fact that the fault handler for this particular RemoteObject accidentally was swallowing faults and not reporting them, and we had a pretty frustrating debugging experience.The point of this little anecdote is that it took too long for the engineers to know that they had some architecture problems because all of their testing was using a local database and simply testing against localhost. So please, as you’re developing, make sure to occasionally test your app from a browser that’s not on the same machine as your server. And if possible have someone outside of your intranet connect to your Flex server and see how the performance goes. If you want to get a real sense of what’s going back and forth you can use a packet sniffer to watch the network traffic (I like ethereal). You’ll be able to see how many images are requested (also a big deal when distance is involved), the size of your data, and even what some of that data looks like on the wire.Testing this kind of stuff early yourself can save you from some real pain later on. You don’t want QA to start complaining the first time they try your app (or even worse, your VP looking from home).