This content has been marked as final. Show 2 replies
The notes provided here can maybe help you out: http://docs.oracle.com/cd/E24329_01/web.1211/e24390/jmstuning.htm#CHDIJEFE
There are also some tips provided here (http://docs.oracle.com/cd/E24329_01/web.1211/e24390/jmstuning.htm#i1157046) for tuning
JMS with large messages.
"Another tuning parameter to consider is the chunk size. A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. To reduce memory allocation costs, a server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. The default chunk size is about 4K. Use the following properties to tune the chunk size and the chunk pool size:
weblogic.Chunksize – sets the size of a chunk (in bytes). The primary situation in which this may need to be increased is if request sizes are large. It should be set to values that are multiples of the network’s maximum transfer unit (MTU), after subtracting from the value any Ethernet or TCP header sizes. Set this parameter to the same value on the client and server.
weblogic.utils.io.chunkpoolsize – sets the maximum size of the chunk pool. The default value is 2048. The value may need to be increased if the server starts to allocate and discard chunks in steady state. To determine if the value needs to be increased, monitor the CPU profile or use a memory/ heap profiler for call stacks invoking the constructor weblogic.utils.io.Chunk.
weblogic.PartitionSize – sets the number of pool partitions used (default is 4). The chunk pool can be a source of significant lock contention as each request to access to the pool must be synchronized. Partitioning the thread pool spreads the potential for contention over more than one partition.
For example, we can set the chunksize by using -Dweblogic.Chunksize=65536 on the command-line."
When you are sending the large messages can you also monitor the respective JVM's to see how they are doing
Thanks..will start profiling on a similar enviroment ...but indeed defaults are not ok...and tuning is a must do.