[JDEV] Sparse considerations about server status

[Gian Filippo Pinzari]

Sorry if I begin with something off-topic. I've just read this 
message on the list:

"jabber at msg.net" wrote:
> 
> I wouldn't worry too much about the hardware specification- with the
> current Open Source server, you'll hit the hard socket limit (1024 in
> many Unix-like OSes) on your primary jabber server process long before
> you run into any memory or CPU speed limitations.
> 
> The Jabber Commercial Server gets around these limitations by using
> true 'pthreads' instead of pth, and polished implementations of code for
> polling, and server farming.

And then again:

> Running the Open Source server, you'll hit other limitations and bottlenecks
> in the server source, such as pth, the flat directory structure of xdb_file,
> blocking issues, etc.

I was a little bit shocked. Reading these considerations anyone
would argue that 'serious' guys should buy the commercial server...
This is unfortunate as it was like reading on Apache mailing list 
someone implying that you should buy a Netscape Enterprise Server 
license to get rid of Apache's flaws. I thought this mailing list 
was to deal with the OpenSource server. Removing bottlenecks and 
blocking issues or improving speed of xdb_files access is just a 
matter of rewriting some code. I'd rather expect someone respond
"please, take your breath, we are working hard to solve these 
problems". Or, that's the same if not better, "the problem is 
maybe in concurrent locking of xyz. Stop complaining and go in 
file xyz.c to see if you can do anything". 

A few days ago there was a post by Dustin Puryear about messages 
being dropped by server. He made benchmarks and found something 
interesting:

> Notice that at >= 120 user pairs (240 connected users), which equates to 
> 120 msg/sec in this test, my message loss rate varies from 3% to 13%. 
> The average delivery also climbs to .14 seconds, but I don't consider 
> that a problem. (However, the worst case delivery times are bad: > 6 
> seconds for 150 and 160 user pairs.)

We've just developed a project (client+server) for one of the 
biggest ISP in Italy. We found since the beginning that each 
Jabber server was not able to handle more than a couple hundreds 
client, so we implemented an architecture that load balances the 
traffic among many concurrent servers running on the same or 
different hosts. We also encountered message losses, but we didn't 
care much :-). As Dustin, we thought this was due to client 
problems.

Though I've been keeping on this mailing list since some time, 
I still haven't figured directions taken in development of the 
next generation server, the one that's supposed to solve some
of the issues listed above. I've read sparse notes but I was not 
able to find any design document and any time plan.

It seems to me that most effort is thrown in having a fully
multithreaded Jabber server. I think multithreading is only 
one aspect of the whole problem, and something I wouldn't wait 
one year to have. If the design is correct, all scalability 
problems of such an application can be solved by load balancing 
and server farming. Multi-thread pertains more to performance 
problem space (the time needed to carry out a request) than to 
scalability (the number of users that can access a service). 
The most perfect multi-threaded implementation will serve as 
many users as can be handled by the most powerful server you 
can buy today. This limitation doesn't fit well in the Internet 
Age.

I'd like to know if anybody has already proposed complete 
separation between implementation of application logic and 
implementation of client-server and server-server networking, 
so that different groups of developers could try different 
implementations. We are trying to build a - single user Jabber 
server - that is a server that just handle 1 connection and 
is able to forward messages to other processeses/clients on 
local or remote hosts. This doesn't appear straightforward. 
Any help?

You could wonder why someone is doing something so stupid.
Well, we are developing an Apache-based Jabber server. Apache 
2.0 is built not just to provide HTTP, but any network protocol, 
connected and not-connected. This is not like the mod_jabber 
many people have been talking about.

This is from Jeremie, 1999:

> What we *really* need is a mod_jabber for apache, so that apache can
> handle all of the needed HTTP functionality and mod_jabber would connect
> to a jabber server and convert the fragements back and forth.  This would
> be useful not only for XML-RPC, but for HTML based clients, dynamic
> pages showing a user's status, showing page visitors live in a jabber
> client, querying administrative apache variables, php integration, file
> transfers, and on and on...

The mod_jabber we have in mind would not be an adapter, but a real 
Jabber server. To me, this idea looks so obvious that I'm sure 
someone has already proposed it before. Here are some pros:

- Multithreaded networking already implemented
  in Apache 2.0.
- Performances. For an off-the-shelf Apache 1.3 
  server, 200 dynamic requests per-second (to cite 
  an apparent Jabber server limit) are nothing.
- Ready made ports for your CPU and OS.
- Added security by massive peer review of Apache
  code.
- HTTP transport, SSL, extended logging at no cost.
- Plenty of bindings to different languages.
- Backends to every database system under the sun.
- Java integration.
- Peer-to-peer, messaging and presence management
  easily built in existing portal infrastructures.
- The wealth of nice programmers already behind
  the Apache Project.


Gian Filippo Pinzari
Medialogic - Italy