Thanks all for replies (and for the jmap/jps idea, hadn't thought of that for some reason).
I tried increasing the maxThreads on the NioReceviever and noticed no performance gain. I then modified the poolSize on the Transport element to 100 and saw no performance gain. This actually didn't surprise me after I discovered how large the sessions were. Using JMX (VisualVM) I watched the Heap size on my two servers as I tested 7000 sessions. Heap climbed approximately 1GB. When I restarted node2, I watched node1's heap usage nearly double. This confirmed my suspicion that the replication process is putting a copy of all sessions into a new object (list I suppose?) before transmitting them. After replication finished (109 seconds), node1's heap usage went back to normal. The aggregation of sessions into a new object to be sent (I presume as part of the handleGET_ALL_SESSIONS?) seems to work quickly, though I'm not sure how to test how much of the 109 seconds it took to replicate was Tomcat gathering up all the sessions to send and how much was network traffic. We have a low utilization gigabit ethernet fabric connecting all servers, so transferring 1GB of data shouldn't take more than 10-12 seconds. Does anyone know if there are ways to time the different steps in the replication process? If it is the network send/receive process that's slow, are there transmit/receive settings for the sender/receiver that could aid in speeding up replication of large data chunks? I see there are rxBufSize and txBufSize settings on the Receiver and Transport elements, and they're set to 25/43kb. If those values represents how data is chunked then larger settings might help (similar to the throughput difference of transferring 100x 10MB files vs. 10,000x 100kb files on a network). Any feedback is always appreciated. I will be able to test any suggestions later tonight and I'll be sure to report back if we make some headway. I'm sure this topic would be useful to others in the future. Thanks, Kyle Harper > What has me stumped is why the time required to do more sessions is > exponentially higher beyond 1500 sessions. Using JMeter I can simulate > 3600 new users (all creating a session) and the two servers can serve the > requests AND generate/replicate the sessions in under 19 seconds. Any > ideas would be greatly appreciated. I have a full test environment to > simulate anything you might recommend. > Maybe that's the boundary for the 6 threads used for the messages between the cluster members, having in mind the huge size of your sessions? By default the Sender uses 25 simultanious connections to each of the other nodes so maybe increasing this pool might speed up the things (poolSize value inside the Transport element of the Sender)? This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ยง 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
