[JDEV] scaling a single server?

[Jacob O'Reilly]

-----Original Message-----
From: Dave Smith <dsmith at ai.uwf.edu>
To: jdev at jabber.org <jdev at jabber.org>
Date: Saturday, 5 February 2000 05:14
Subject: Re: [JDEV] scaling a single server?


>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?

[...snip...]

>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.

Firstly, I was not suggesting that anyone used UDP, it was an observation
about other systems and techniques.  However, on the flip side of that,
having your own built-in TCP layer above UDP does allow you to use the
resources where they are most abundant and not push resources where they are
lacking.  Memory for 25K connections is easier to find than a box that will
maintain 25K TCP connections.  Personally, I don't think the hardware to
support that many users is within the reach of most people -- for whatever
reason!

>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.. :)


It would seem to me that using mass-produced hardware (as you now see used
by web providers) offers much better scalability -- if the architecture is
fit for the task.  I make no judgement about that!

>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. :)

Sounds good to me.  I have experience with traditional products that do not
scale very well, and they are usually not beyond repair, but they are
commonly out of the reach of the customer to change (as is usual for
commercial products.)

It would seem to me that the person that started this thread would be after
multiple smaller boxes.  Can you imagine the MS Exchange architecture to
support 25K clients?   Nightmare...

>
>D.
>

-- Jacob.