In addition to "RG's" suggestion, I would:
1.) Set use_direct_buffer = false (Grizzly will use HeapByteBuffer instead)
2.) You might also reduce the number of instances of the server down to
2 or even 1. NIO should give you much better scalability and should
have no problems scaling to 12,000 connections.
3.) If you can, I would also go to the latest JDK 6_02 version.
We might also need to do some further fine tuning of the JVM too.
Could you share with us the full java command line args you are using?
It might also be useful to see the output from -XX:+PrintGCDetails when
you are running with NIO.
hths,
charlie ...
Fay Zheng wrote:
> We add Grizzly Nio engine to one of existing server, which used to be
> one thread per connection classic model. During load test we noticed
> that NIO server consumes twice CPU power than the classic model when
> serving the same amount of connections.
>
> Here's our configurations:
>
> Here are some statistics:
>
> Hardware: Dells 2950 with 16 GB RAM, total 8 processors, Intel(R)
> Xeon(R) CPU E5345 @ 2.33GHz , Linux kernel 2.6
>
> Software: JDK v1.5.6
>
> There are 4 instance of the server application configured on one box
>
> Grizzly Configs:
>
> 100 max worker threads (8K buffer size)
>
> 150 max output buffer pool size (4K buffer size)
>
> use_direct_buffer = true
>
> selector timeout = 500
>
> Keep alive is true (persistent connections)
>
>
> Tested with : 7200 client connections
>
> Total CPU usage for all 4 instances are 44.59% (with NIO engine)
>
> CPU usage is 24.76% (without Nio engine)
>
> So far as memory, NIO server uses slightly less memory in this case.
>
>
> The memory consumption could be linear because we keep lots of state
> information for each connection (user). Other than that, what other
> parameters should I pay attention to in order to scale the server to
> serve 10,000 or more connections without burning up CPU?
>
> The old server can serve 12000 connections with 4 instance at <= 50%
> CPU usage.
>
> Would it be better to run 2 instances of NIO server instead of 4?
>
> Your opinion and suggestion is greatly appreciated.
>
>
> thanks,
> Fay
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>