Chapter 16. Building Scalable Applications

Most production applications require more than one application instance. For example, a chat room system may have several lobby application instances running at the same time, as well as many chat room instances. In fact, instances of an application may be running on more than one server. Some of the good reasons to partition an application across multiple instances on one or more servers are as follows :

Performance

Each instance has a single ActionScript thread, which can constitute a bottleneck. Using multiple instances allows for multiple simultaneous threads.

Separation of resources

Clients that need common access to the same shared objects and streams can be grouped into separate instances.

Scalability

As the number of clients increases, a single server may not be able to handle the load. Adding CPUs, RAM, and network cards to a single server increases its capacity to handle more clients, but only up to a point. Placing separate instances on different servers allows applications to scale to accommodate as many clients as necessary.

Failover

When an instance or server fails, instances on another server can take over so that clients can reconnect and continue working.

A multi-instance application should still appear as one seamless application to the user. For example, a multiroom chat system can provide a global user list that shows who is online despite the fact that users are connected to different instances (perhaps on different servers). Where multiple lobbies are used, a user connected to one lobby should be able to invite users connected to other lobby instances to connect to a chat instance.

This chapter introduces some of the problems of coordinating multiple instances that make up an application, scaling applications across multiple servers, and providing failover. It provides some guidance on how to approach building multi-instance applications and gives some examples. However, it does not present a single n -tiered architecture as is common for web-based applications. One reason a single architecture is not presented is that there are so many different types of FlashCom applications. Another reason is that shared objects and streams can be directly updated by one master instance only. Custom ActionScript is required to provide access to streams and shared objects to other instances.

Some of the hosting companies cited in the Preface offer scalable, fault-tolerant FlashCom application hosting of their own on-demand and live streaming applications. However, it is very difficult for hosting companies to offer scalable and fault-tolerant standard hosting packages for customer-written applications because each application will have different requirements. Some vendors are willing to negotiate custom agreements for multiserver hosting.