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.
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?
Comments are closed.