Thank you! We've already override the expire method in the
DefaultSelectionKeyHandler to do nothing for our application:
DefaultSelectionKeyHandler keyHandler = *new* DefaultSelectionKeyHandler() {
*public* *void* expire(SelectionKey key) {
*return*;
}
};
However this approach looks quiet expensive in the profiling data. For now I
have to customize the grizzly source code to remove the expiring of key
part.
thanks,
Fay
On 8/13/07, charlie hunt <charlie.hunt_at_sun.com> wrote:
>
> Hi Fay,
>
> At the moment, there is not a way to turn off expiring of a key.
>
> But, it is functionality we should have and I know of another project
> which will want this functionality disabled as well.
>
> I will file an enhancement issue to add this functionality.
>
> charlie ...
>
> Fay Zheng wrote:
> > Is there a way to turn off expire of key, since it is not applicable
> > to persistent connections:
> >
> > iterator = readyKeys.iterator();
> >
> > while (iterator.hasNext() && selectorHandler.isOpen()) {
> >
> > key = iterator.next();
> >
> > selectionKeyHandler.expire(key);
> >
> >
> >
> > thanks,
> >
> > Fay
> >
> >
> >
> >
> > On 8/10/07, *Fay Zheng* <fzheng1998_at_gmail.com
> > <mailto:fzheng1998_at_gmail.com>> wrote:
> >
> > Here's the command to run the application:
> >
> > java -server -verbose:gc -XX:+PrintGC
> > Details -XX:+PrintGCTimeStamps -
> > Dcom.pg.env=/props/env/dev/pg/trx.properties
> > -Dcom.sun.management.jmxremote
> > -Dcom.sun.management.jmxremote.port=9991
> > -Dcom.sun.management.jmxremote.authenticate=false
> > -Dcom.sun.management.jmxremote.ssl=false
> > -Duser.region=US -Xmx700m com.pg.serv.room.Main
> >
> > The GC is almost 10% for NIO, 5% for none NIO server.
> >
> > thansk,
> > Fay
> >
> > On 8/8/07, *charlie hunt* < charlie.hunt_at_sun.com
> > <mailto:charlie.hunt_at_sun.com>> wrote:
> >
> > 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/
> > <http://java.sun.com/docs/performance/>>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> > <mailto:dev-help_at_grizzly.dev.java.net>
> >
> >
> >
>
> --
>
> Charlie Hunt
> Java Performance Engineer
> 630.285.7708 x47708 (Internal)
>
> <http://java.sun.com/docs/performance/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>