[JDEV] scaling a single server?

[Dave Smith]

It is *not* a traditional client/server design -- this is especially obvious
by the long-lived TCP connection.
Of course, the question is *why* would we want to make such a radical
departure from tradition? Check out what jer had to say on JDEV way back
when the project first started growing:

> From jeremie at jabber.org Mon, 9 Aug 1999 18:45:10 -0500 (CDT)
> Subject: [JDEV] EVERYTHING (re: mime/file-xfer/ctcp/etc)
> ...
> The main goal behind Jabber is to provide an architecture that can support
> absolutely simple clients that can speak transparently to a variety of
> different real-time messaging services.  Jabber is a solution based around
> the server.  (for lots of other reasons, which IS a dissertation I'll be
> writing sometime soon :)  For a client to be able to do client to client
> conenctions it would have to understand ICQ, AIM, etc, etc protocols
> directly, and that is exactly what Jabber is NOT. ...

In my mind, it's critical that we remember the whole point of Jabber. It's
about simple clients and fairly complex servers. That being said, there will
be a propensity towards scaling issues. Ok, we know it's an issue, so what
solutions are available?

1.) UDP v.s.TCP
    It is an arguable point that UDP requires more resources than TCP. A
process which is waiting on a UDP socket and a process which is waiting on a
TCP socket should both use no processor time (assuming a fairly efficient
kernel and scheduler). That fact aside, let's also consider the nature of
UDP.  By design, UDP is a unreliable protocol -- this means that packets
sent via UDP are not guaranteed to arrive in order, if at all. This means
that interaction between the client and server would require a more complex
protocol for ensuring complete, orderly delivery of packets. Imagine
sending: <foo>bar</foo> over UDP and recv'ing </foo><foo>bar at the other
end! The only way to avoid a fiasco like this would be to implement a whole
layer of transmission control (ala TCP) at the application level on both the
server *and* client. Why do that?! My point here is this: you'd have to
implement TCP at one level or another in order to stream XML properly.
Remember, we're not just sending little binary packets around; this is XML
data! The amount of processing time would be rougly equivalent and the
client implementation complexity would significantly increase. If the main
goal behind Jabber is to implement simple clients, this is *not* the way to
go.

2.) Single server vs. Multiple servers
     <future-rant>The traditional approach to dealing with thousands of
simultaneous users is to buy some "big iron" machine that can handle the
concentrated load. I would like to suggest that this is something which will
change in the future as systems become more and more "permanently"
interconnected (i.e. connected for a relatively long period of time).  I
believe there will be a shift towards using multiple, lighter-weight servers
which distribute the load among them (ala the Borg). This architecture would
lend itself to scaling and robustness as it would be somewhat redundant in
design, yet easily (and cheaply) expandable. I believe this will especially
be an issue in developing nations (such as India) where it's significantly
cheaper to buy multiple small machines than one big one (note: I grew up in
SE Asia, so i've personally experienced this). </future-rant>
    Additionally, I would like to point out that for handling a large number
of users in an application such as instant messaging, it's atypical to use a
single, unoptimized server. That is, if you *are* going to serve up 25k hits
simultaneously (whether it be over UDP/TCP, web-serving or IM) you're *not*
going to use a unoptimized kernel on a single machine. At least, I
wouldn't.. :)

IMHO, Jabber already has the makings of an excellent distributed system,
thanks to the modular design of etherx/jserver. Obviously we need to start
tackling issues of scalability and robustness -- I, for one, would enjoy
this task. Above all else, we must remember though that Jabber is *not* a
traditional implementation. Therefore, let's not confine ourselves to
traditional solutions. :)

D.