[JDEV] Stress testing and connection limits

[Eric Bowersox]

> ulimit on my Linux server that jserver is running on reports 
> 1024 open file
> handles. I've tried changing that number with ulimit but I'm 
> not sure if the
> number of handles really changes. I don't think so.

It's not the number of open file handles that is set with ulimit that
matters, it's the maximum number of file handles in a select() call.  This
is limited by factors which are set at compile time and difficult to change
(see below).

> The 
> implication from
> what you've said is that the max number of jabber users 
> connected at one
> point is limited. In my case, 1024. Is that true? Isn't that as fairly
> serious restriction? I was expecting to have a powerful 
> server with 10's
> maybe 100's of thousands of connected users.

I agree, it's serious.  That's why the server developers (Jer and temas,
namely) are working their asses off to develop the "mux" solution.

> Can the kernel 
> be rebuilt with
> a larger size? If I change the limit to 100,000 or 200,000, 
> will Linux still
> run?

Again, the number of file handles the kernel has is *not relevant* here,
because the kernel has way more handles available already than a single
select() can use.  The problem is with the size of the FD_SET structure that
select() uses.  This structure's size is fixed at compile time, and almost
certainly cannot be changed without severe breakage in many places (such as
the C library).

I have a feeling this is why poll() was introduced, to get around the
restrictions of select(). However, that doesn't help us, as pth uses
select() as part of the very core of its event-handling system, and pth is
some heavy hoodoo-voodoo at the center of the Jabber server, so attempting
to modify it would be "Not Recommended."

					Eric