tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kharp...@oreillyauto.com
Subject Re: Tuning session replication on clusters
Date Thu, 06 Sep 2012 13:10:26 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message