[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Kyle Cordes wrote:
> > No, my chat application used plain RMI ;-) Actually, I got 18.000
> > messages at peak (Athlon 650Mhz, 128Mb RAM).
> With how many connected clients? I am interested in how to build MOM
> systems that can handle a large number of connected clients, each
> generating few messages, but with many messages being "broadcasted" to a
> large number of clients.
> Most discussions of performance testing seem to center around a
> relatively small number of clients (dozen, hundreds) generating a lot of
> activity each.
> (XML-blaster question: how well does it handling thousands of connected
I've added a new test case to our testsuite:
java -Xms10m -Xmx220m testsuite.org.xmlBlaster.TestSubManyClients
-numClients 10000 -client.protocol RMI
Running xmlBlaster and "TestSubManyClients" on the same machine.
There are in this example 10-thousand clients which login to xmlBlaster
For RMI, every login consums ~9 kByte on the server,
for CORBA ~11 kByte per login.
All 10.000 clients subscribe to a message.
A publisher client then publishes this message which is
updated to all 10.000 clients.
With CORBA, 435 messages/sec are delivered (all on the same machine)
> (Java question: I know that various JVMs have issues with a large number
> of connected sockets, deriving from the need to have a thread (or more)
> for every one, in the current Java networking APIs. How high could Java
> reasonably go before this becomes a problem?)
With POA/CORBA the server request handling is finegrained adjustable,
here i used 'one thread per request' policy (using a thread pool).
With RMI no server policy is adjustable, looking into Suns java code
shows us, that they use 'one thread per request' policy as well
(but this is nowhere specified).
In both cases, the number of clients is only limited
by the amount of memory (RAM) you have on your server.
Java shouldn't care about the number of thread, but
the OS will.
For Linux < 2.4 the number of threads are limited
per default to 256 (processes == threads).
With the new Linux 2.4 kernel, there is no limit (i think
it is 32 thousand threads).
My tests are made on a Linux 2.2 box, so even the small
number of available threads was no problem.
mailto:ruff at swand.lake.de