Building Scalable Servers
As part of my new iPhone project to build a new game, I need to have a backend server to communicate with all the members in order to sync and dynamically update on the fly. Knowing the iPhone and its possibilities, I want to plan for a highly optimistic future in which thousands of concurrent connections take place. The transactions will be minimal and compressed to conserve bandwidth, but will occur frequently to monitor player actions and provide alerts to other players as they are interacted with. So, my immediate question was where do I start. I obviously have two primary choices: HTTP or proprietary. Let’s look into each option a little more in depth.
First, let’s look into HTTP and what it can buy us. To start, HTTP is a highly supported protocol. However, it is stateless and connections come and go. As I am planning on several small messages, opening/closing connections would kill the system as the latency involved for opening/closing would be more than the short messages. HTTP 1.1 does support keepalive to keep those connections open, but then you depend on the client properly handling that as well as proxy servers from routing it accordingly. That seems too risky in my opinion. Further, HTTP has heavy payloads involved with its request/response headers. Again, remember that my messages will be very short, so any type of overhead will only decrease throughput and concurrency. The one area where HTTP will be a huge benefit is the number of available servers. Using a comet-based system, you can create pretty high throughput systems via NIO connectors available in servlet engines such as Jetty, Tomcat, and Glassfish. There are also several non-servlet based HTTP containers that support NIO connectors. Overall, I think the connection handling and payload issues are too much for my server to really scale in an optimistic future.
So, that leaves me with option two: proprietary. In any sense, the key here is an NIO-based system. NIO (or non-blocking I/O) is a JDK 1.4+ feature that allows non-blocking I/O to occur so that servers can scale without requiring separate worker threads per connections. Instead you listen for selection events on the sockets and immediately respond as they occur. Thus, you can scale to thousands of connections without requiring thousands of threads which only limit concurrency and increase memory. There are several non-HTTP-based NIO servers and then there is building and designing a custom one to fit the exact needs and protocol of the architecture. However, trying to build a custom NIO solution requires months of investigation, testing, configuring, fine tuning, etc. Several parties have spents countless hours trying to perfect scalable NIO solutions. Thus, it only makes sense to leverage those technologies. For my intents and purposes, I am going to evaluate four of the main java-based solutions:
In order to gauge an idea at each of these solutions I did some simple performance tests and some personal usability tests in terms of ease of use, implementation, and feature set. These tests will be provided in subsequent blog entries.
Leave a Reply