Zimbra

Our discussion of Zimbra server scaling has engendered at least one spin-off: The question of the impact of rich Ajax client applications on the servers that support them. Let’s consider the big picture first, and then we will dig into Ajax …

Applications broadly consist of UI logic, business logic, and data (access & update) logic. In the old days, all of this logic ran on a “mainframe” server, which meant that per user operation, the server was responsible for doing all of the work. Traditional fat client applications, on the other hand, off-load all of the UI and most of the business logic (modulo stored procedures and triggers) from the server to the client. Fat client app’s could nevertheless hammer their servers simply by not being sophisticated about how much and how often data was being requested—that is, data shipping to the client can be more expensive than function shipping to the server (with stored procedures, triggers, et al). With a reasonably smart design, however, fat client applications typically use more client and less server CPU per operation than a corresponding server-centric application.

In terms of its broader application architecture, the Web platform looks a lot more like a mainframe application: Yes, the 3270 green screen is replaced by a far richer browser and hypertext mark-up, but more of the UI and virtually all of the business logic (modulo Javascript field validation) is done on the server. (Indeed, one of the big frustrations application architects continue to have with the typical Internet application is that while we advocated a strong separation of UI logic (JSP) from business logic (JavaBeans, EJBs) and data logic (JDBC), many applications violate modular design principals by sprinkling JDBC calls directly into their JSPs.) Of course, the fat client model simply does not work on the Web: organizations can ill afford to ship their business-critical, confidential data off for untrusted applications to manipulate. However, we should recognize that in general Web applications are inherently more expensive in terms of server load than traditional client server, because the server code is also responsible for the computationally-significant UI work of constructing the HTML response for each HTTP request.

Now to Ajax. I’ve been describing Ajax as a husky client architecture (somewhere between “thin” and “fat”, but with the deployment advantages of “thin”) because the network boundary between client- and server-side code is defined by the application programmer! The client consumes an XML network binding to a reusable application service (think service-oriented architecture or SOA). That is precisely the modular separation that Web application architects have been advocating for years, even when all of the actually code was running on the server-side. I believe the largest benefit of Ajax and SOA is in re-use, security, and maintenance, but there are significant performance ramifications as well. Specifically, compared to a traditional Web application, Ajax/SOA app’s consume less server-side CPU, because the UI processing is off-loaded to the client (just watch your CPU meter when Ajax is getting crunched in your browser).

No doubt, this is a generalization: The Ajax/SOA architecture requires that the client generate XML invocations for the server and then parse the XML (or interpret JSON) responses. Since XML processing is computational expensive on the server as well as the client, it is definitely possible to craft poorly performing Ajax applications. But in general, the performance hurdles in realizing Ajax are browser-based rather than server-based, simply because the UI computation has been off-loaded to the client. In fact, Ajax applications tend to go to the server more often than typical Web applications, since the cost of the server invocation to, say, get my appointments when I mouse-over a date, is far cheaper on both the server and the network than generating a new page (especially when the result set is cached for subsequent access). That finer granularity of access does require that Ajax server logic be more stateful than some Web applications (although the broad trend there is to statefulness as well). However, in terms of the server-side workload, our claim (borne out by our experience to date) is that the typical Ajax application will have a smaller footprint than an analogous Web application. The same is true of network bandwidth—Ajax applications generally consume less than traditional Web app’s, with the caveat that the initial download of the Ajax client code can be a significant hit if you’re not on broadband.

Most importantly, however, is the fact that the interface between Ajax client and server application (whether it is written in Java, C#, PHP, or Ruby on Rails) is chosen by the application designer. Spend effort choosing that boundary well—for modularity, for re-use/mash-up, for security, for performance, and for longevity—and server workload will be far less of a challenge than it otherwise would be.

Just an aging Web/Java architect’s $.02. Thoughts?