Scaling to the Enterprise (Part 2 of 4)

2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)

The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user’s computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.

When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe’s law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed’s 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed’s discussion for a surprisingly accessible treatment of value, saturation, and other issues.)

Because of this, we have developed a P2P architecture, in which each user’s own machine handles the load for the user. In fact, it replicates the work done for all users in the same group, so that the number of machines used exactly matches the load, and these machines are supplied by the users themselves. [I imagine that Croquet 1.0 may require storage on each user’s machine in proportion to the number of groups the user has joined. However, there’s no reason that the storage for each group can’t be broken up among all the members of the group, ala BitTorrent or DHTs, such that your own storage for each particular group is on the order of 1/n_members_of_group.]

Furthermore, the stateless architecture of the Web requires that a Web-app server must reproduce a lot of application state in response to each user request. The amount of processing required for each request is roughly proportional to the size of the entire application, not the size of the small state change actually requested by the user. (To be fair, this is mostly a WWW issue. Not all client-server architectures require this.) By contrast, Croquet applications maintain state between gestures, and so do not suffer from this problem.

In combination then, Croquet user machines are asked to perform a relatively modest amount of work. Even with 3D graphics and the current unoptimized condition of Croquet, this amount of work is well within the abilities of fast personal machines. With the abilities of personal machines growing, and Croquet getting “smarter” about bottlenecks, this will only get better. In particular, it does NOT get worse as the number of users goes up. In other words, what you see now is as bad as it gets.

There will also be some other machines (which I expect in practice will be provided by a combination of end users and institutions), which are sometimes referred to as super-peers or interactivity servers. These are ordinary Croquet clients, running ordinary Croquet software, including Squeak, but which provide a certain aspects of stability for persistence and rendevous. We believe their load is no worse than linear with the number of users of their particular service (e.g., the number of users of a particular group).

Now, there will be several uses of big-iron servers in Croquet educational applications. They will be used for providing authoritative versions of objects, for searching, and for interfacing with external and centrally run systems such as user authentication. However, the load from this is relatively small, and is outside of Squeak. For example, where we now have a Java sever running, say, Signet, this sever will continue to work unaltered. Croquet will simply be another client.