> The mod_perl servers are the work horses, just like the custom > servers. In a classical OLTP system, the customer servers are > stateless, that is, if a server goes down, the TM/mod_proxy server > routes around it. (The TM rollsback any transactions and restarts the > entire request, which is interesting but irrelevant for this > discussion.) If the work servers are fully loaded, you simply add > more hardware. If all the servers are stateless, the system scales > linearly, i.e. the number of servers is directly proportional to the > number of users that can be served.
The mod_perl servers in the eToys setup were essentially stateless. They had some local caching of user-specific data which made it desirable to go back to the same one if possible for the same user, but it would still work if the user switched to another server, since all state was stored in the central database. The trouble here should be obvious: sooner or later it becomes hard to scale the database. You can cache the read-only data, but the read/write data isn't so simple. Theoretically, the big players like Oracle and DB2 offer clustering solutions to deal with this, but they don't seem to get used very often. Other sites find ways to divide their traffic up (users 1 - n go to this database, n - m go to that one, etc.) However, you can usually scale up enough just by getting a bigger box to run your database on until you reach the reach the realm of Yahoo and Amazon, so this doesn't become an issue for most sites. > If the whole multi-threaded server ever has to wait on > a single shared resource (e.g. the garbage collector), all > simultaneous requests in progress lose. This doesn't happen if the > work servers are single threaded, i.e. "shared nothing". You can > easily model the resources required to process a request and no > request has to wait on another, except to get CPU. But how can you actually make a shared nothing system for a commerce web site? They may not be sharing local memory, but you'll need read/write access to the same data, which means shared locking and waiting somewhere along the line. > The front-end servers are different. They do no work. Their job is > switching requests/responses. Some of the requests are going directly > to the OS (e.g. get an icon) and others are going to the work servers. > The front-end servers "wait" most of the time. Here I buy into the > the asynchronous I/O model of serving multiple requests and not the > lightweight process model. I do feel that servers built on non-blocking I/O would have been much more efficient on the eToys front end. I've seen how well thttpd can do. But since these boxes already scaled well beyond our needs with basic Apache/mod_proxy, we didn't bother to look for something more complicated. If I ran into problems with this now, I would probably look at Red Hat's Tux server. - Perrin
