investigate what Objects that are worth caching and not

[glassfishrobot]

Investigate what Objects that are worth caching.

Some of the objects cached in grizzly , like SelectionKeyOP are obvious performance losses. (the CLQ internal node wrapper has the same alloc and GC cost, add do that the non trivial concurrent overhead for the queue logic).

Will use this issue to attach data from grizzly-cachetest to back it up.

I only have an intel core2 cpu. I will perform the tests in GF v3 from trunk , opensolaris 105+ using jdk 1.6 and 1.7.

If someone can contribute with tests run on more cores and or other cpu architectures it would be great.

feedback and ideas for improvements of grizzly-cachetest are also welcome on the dev list.

Environment

Operating System: All Platform: All

Affected Versions

[1.9.4]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/grizzly/issues/379
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented Reported by gustav3d@java.net

[glassfishrobot]

@glassfishrobot Commented gustav3d@java.net said: for the allready commited svn r2189 patch to trunk, heres some data for the most expensive to instance of the to classes the patch affected:

JVM: Sun Microsystems Inc. Java HotSpot(TM) Server VM 14.0-b09 JVM params: [-XX:+AggressiveOpts, -Xms512m, -Xmx512m, -XX:+UseParallelOldGC, -XX:+UseParallelGC] Starting calibration. Starting tests. estimated running time is 27 minutes +-10% CPU:2 Threads:1 5990 K ConnectSelectionKeyOP/sec ConcurrentLinkedQueue time 460 sec. CPU:2 Threads:1 13578 K ConnectSelectionKeyOP/sec LinkedTransferQueue time 172 sec. CPU:2 Threads:1 94554 K ConnectSelectionKeyOP/sec new Instance time 176 sec. CPU:2 Threads:8 6079 K ConnectSelectionKeyOP/sec ConcurrentLinkedQueue time 146 sec. CPU:2 Threads:8 13537 K ConnectSelectionKeyOP/sec LinkedTransferQueue time 147 sec. CPU:2 Threads:8 97794 K ConnectSelectionKeyOP/sec new Instance time 176 sec. CPU:2 Threads:64 5933 K ConnectSelectionKeyOP/sec ConcurrentLinkedQueue time 176 sec. CPU:2 Threads:64 13350 K ConnectSelectionKeyOP/sec LinkedTransferQueue time 180 sec. CPU:2 Threads:64 92171 K ConnectSelectionKeyOP/sec new Instance time 179 sec.

[glassfishrobot]

@glassfishrobot Commented gustav3d@java.net said: LTQ doubles the throughput compared to CLQ in java 1.5 too:

on opensolaris 105: JVM: Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM 1.5.0_17-b04 JVM params: [-XX:+AggressiveOpts]

CPU:2 Threads:8 4072 K String/sec ConcurrentLinkedQueue CPU:2 Threads:8 8703 K String/sec LinkedTransferQueue

this is massive performance improvement for our object caching.

doug lea told me yesterday on a direct question that he considers LTQ to be production stable. also that CLQ will delegate to LTQ in java 1.7.

I have had it running for some hours on my system in the cachetest.

I will change the caching CLQ to LTQ in grizzly.

[glassfishrobot]

@glassfishrobot Commented gustav3d@java.net said: Sending NetBeansProjects/trunk/modules/utils/src/main/java/com/sun/grizzly/util/ConcurrentLinkedQueuePool.java Adding NetBeansProjects/trunk/modules/utils/src/main/java/com/sun/grizzly/util/LinkedTransferQueue.java Adding NetBeansProjects/trunk/modules/utils/src/main/java/com/sun/grizzly/util/TransferQueue.java Transmitting file data ... Committed revision 2224. Sending NetBeansProjects/trunk/modules/portunif/src/main/java/com/sun/grizzly/portunif/PUReadFilter.java Sending NetBeansProjects/trunk/modules/rcm/src/main/java/com/sun/grizzly/rcm/ResourceAllocationFilter.java Transmitting file data .. Committed revision 2225.

Sending NetBeansProjects/trunk/extras/cachetest/src/main/java/com/sun/grizzly/test/cachetest/ConcurrentCacheTester.java Sending NetBeansProjects/trunk/modules/comet/src/main/java/com/sun/grizzly/comet/CometEngine.java Sending NetBeansProjects/trunk/modules/comet/src/main/java/com/sun/grizzly/comet/CometSelector.java Sending NetBeansProjects/trunk/modules/cometd/src/main/java/com/sun/grizzly/cometd/BayeuxParser.java Sending NetBeansProjects/trunk/modules/cometd/src/main/java/com/sun/grizzly/cometd/DataHandler.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/ConnectorInstanceHandler.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/Controller.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/DefaultProtocolChainInstanceHandler.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/TCPSelectorHandler.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/async/AbstractAsyncQueueReader.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/async/AbstractAsyncQueueWriter.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/async/AsyncQueue.java Sending NetBeansProjects/trunk/modules/grizzly/src/main/java/com/sun/grizzly/suspendable/SuspendableMonitor.java Sending NetBeansProjects/trunk/modules/http/src/main/java/com/sun/grizzly/arp/AsyncProtocolFilter.java Sending NetBeansProjects/trunk/modules/http/src/main/java/com/sun/grizzly/arp/DefaultAsyncHandler.java Sending NetBeansProjects/trunk/modules/http/src/main/java/com/sun/grizzly/http/SelectorThread.java Transmitting file data ................ Committed revision 2226.

==[IDE]== Jan 15, 2009 8:00:56 AM Committing... finished.

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Gustav is working on this.

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Bump version.

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Close this issue and instead open one per cache we want to remove.

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Fix target.

[glassfishrobot]

@glassfishrobot Commented Was assigned to gustav3d@java.net

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GRIZZLY-379

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Tuesday, December 15th 2009, 6:27:38 pm