Scalability Recipes

Building scalable FlashCom applications is a challenging undertaking. Each application has different functional requirements and may require a different approach to scalability. I've reserved this part of the site for posting short recipes in cookbook style regarding multi-instance applications, scalability, and failover. I hope to post scalability recipes here in response to questions and as time allows.

Proxied Shared Object Recipes

Proxied shared objects provide a convenient way to share information in real time between application instances. One caution with shared objects is that you can't let them get too big. For example you could design an application that uses a proxied shared object to act as a list of every user in every chat room within a chat system. Every user entry is held in memory in each copy of the shared object. If there are too many simultaneous users on the system at one time the shared object will consume too much memory. Proxied shared objects are therefore a good way to share information on small or medium scale. Large or very larger non-stream information sharing should be done with a database.

1. How Many People are in each Chat Room

Database Recipes

Databases were designed to add, update, delete, and find massive amounts of data efficiently. Unlike shared objects that keep all their data in memory databases provide exceptionally fast access to data on disk. Large and very large scale FlashCom applications can make use of databases to provide features like friend lists and administrative searches of near real time information such as what rooms a user has visited in the last month and where he or she is now.

Document initially posted March 31, 2005 by Brian Lesser