Details
P4 Description
See http://www.javaworld.com/javaworld/jw-03-1999/jw-03-volanomark-2.html
which contains the following content:
"both Sun and Microsoft have artificially crippled the connection
scalability of their Java virtual machines on Windows NT by shipping them
with the default stack reserve of one MB per thread.
Microsoft long ago changed the stack reserve of its own Internet Explorer
4.0 Web browser and Internet Information Server 4.0 Web server, following
the "changed standard for all Windows NT system executables."
Why it didn't apply the same change to its Java VM, or why Sun failed to
pick up the change for its Windows NT port, is unclear.
In any case, it's now time for them to follow IBM's lead and
make this simple, but important, change.
[See URL for the benchmark described below. This shows Sun JDK 1.2
maxing out at 900 connections per sec, while IBM JDK goes to 2100]
VolanoMark 2.1.2 network scalability test of the Sun and Microsoft Java
virtual machines for Windows NT after reducing the stack reserve from 1 MB
to 256 KB per thread. Throughput is reported in messages per second based
on the number of concurrent connections. All tests ran identical copies of
VolanoMark 2.1.2 on identical hardware. The Limit is the maximum
number of simultaneous VolanoMark connections possible.
--
The IBM Win32 JVM achieves a much higher effective thread limit by
reducing the virtual memory reservation per thread from its 1-M default. The
thread stack reservation is specified in the header of the executable and
can be set either via a linker option (/STACKSIZE) at the time the JVM is
built, or even on a prebuilt executable using the editbin utility.
---
However, while making threads thriftier in their resource usage leads to
impressive gains in connection scaling, the thread-per-socket
model simply cannot scale up to tens or hundreds of thousands of concurrent
connections. Some form of multiplexing many connections to a single thread
is required. Native applications traditionally use the select() or poll()
system calls to achieve this. Java does not yet have a select() facility in
its sockets API, but it is clear that one is needed as server-side Java
applications grow in magnitude and scope.
-- end of quote from Rajiv Arora, IBM Corporation
bug filed by linden@eng 1/11/00
which contains the following content:
"both Sun and Microsoft have artificially crippled the connection
scalability of their Java virtual machines on Windows NT by shipping them
with the default stack reserve of one MB per thread.
Microsoft long ago changed the stack reserve of its own Internet Explorer
4.0 Web browser and Internet Information Server 4.0 Web server, following
the "changed standard for all Windows NT system executables."
Why it didn't apply the same change to its Java VM, or why Sun failed to
pick up the change for its Windows NT port, is unclear.
In any case, it's now time for them to follow IBM's lead and
make this simple, but important, change.
[See URL for the benchmark described below. This shows Sun JDK 1.2
maxing out at 900 connections per sec, while IBM JDK goes to 2100]
VolanoMark 2.1.2 network scalability test of the Sun and Microsoft Java
virtual machines for Windows NT after reducing the stack reserve from 1 MB
to 256 KB per thread. Throughput is reported in messages per second based
on the number of concurrent connections. All tests ran identical copies of
VolanoMark 2.1.2 on identical hardware. The Limit is the maximum
number of simultaneous VolanoMark connections possible.
--
The IBM Win32 JVM achieves a much higher effective thread limit by
reducing the virtual memory reservation per thread from its 1-M default. The
thread stack reservation is specified in the header of the executable and
can be set either via a linker option (/STACKSIZE) at the time the JVM is
built, or even on a prebuilt executable using the editbin utility.
---
However, while making threads thriftier in their resource usage leads to
impressive gains in connection scaling, the thread-per-socket
model simply cannot scale up to tens or hundreds of thousands of concurrent
connections. Some form of multiplexing many connections to a single thread
is required. Native applications traditionally use the select() or poll()
system calls to achieve this. Java does not yet have a select() facility in
its sockets API, but it is clear that one is needed as server-side Java
applications grow in magnitude and scope.
-- end of quote from Rajiv Arora, IBM Corporation
bug filed by linden@eng 1/11/00