--On Tuesday, May 29, 2001 21:25:20 -0700 ed phillips <[EMAIL PROTECTED]>
wrote:
> It might be helpful and may even spawn other suggestions if
> you were to flesh out in a post some of the aspects, as you articulate
> them, of scaling Java on Linux. Perhaps a kind of pre-BoF statement of
> the topic to be discussed?
That's a good suggestion. Here goes:
The biggest problem with scaling Java on Linux are threads. No question
about it. Linux 2.4.x is very scalable to even as many as 16 processors,
with excellent network, memory, and disk performance (particularly now with
XFS & ReiserFS). In my experience, most Java applications won't push the
kernel's capabilities in these areas even on a $2000 1U server with a
single processor, and those that do will find Linux scales just as well as
everyone else.
So, the thread issue is a nasty one, particularly if you're say hosting
servlets on Linux. 90% of the reason you need all these threads is due to
the thread-per-IO model in standard Java I/O. Unfortunately, this doesn't
map too efficiently to the 1-1 thread model found in most Linux JVM's.
There are a few strategies for coping with this:
1) Use green threads (people don't normally think of this as an OK solution
for an application server)
2) Have a C or other application multiplex the I/O either over sockets or
JMS.
3) Use lots of boxes & tweak the kernel to allow as many threads as
possible.
4) Use JNI to use Linux's various asynch I/O API's.
The good news is Linux's thread model is moving in a direction to better
support Java's approach to I/O (IBM's next generation pthreads
implementation), and Java's approach to I/O (NIO) is moving closer to the
efficient way to do I/O with Linux. Indeed, we're working on some
benchmarks right now for #4 and also using NIO to see just how far Linux
will go. My bet is Linux is actually going to prove very cost-effective in
terms of scalability with this stuff.
--Chris
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
