fhanik 2004/01/09 15:36:34
Modified: catalina/src/conf server.xml
webapps/docs cluster-howto.xml
Log:
Set the default replication mode to be pooled, for faster performance
Revision Changes Path
1.28 +3 -2 jakarta-tomcat-catalina/catalina/src/conf/server.xml
Index: server.xml
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server.xml,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- server.xml 9 Jan 2004 23:28:23 -0000 1.27
+++ server.xml 9 Jan 2004 23:36:33 -0000 1.28
@@ -283,15 +283,16 @@
mcastPort="45564"
mcastFrequency="500"
mcastDropTime="3000"
- tcpThreadCount="2"
+ tcpThreadCount="6"
tcpListenAddress="auto"
tcpListenPort="4001"
tcpSelectorTimeout="100"
printToScreen="false"
expireSessionsOnShutdown="false"
useDirtyFlag="true"
- replicationMode="synchronous"
+ replicationMode="pooled"
/>
+
-->
<!--
When configuring for clustering, you also add in a valve to catch all
the requests
1.4 +11 -5 jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml
Index: cluster-howto.xml
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- cluster-howto.xml 22 Dec 2003 15:18:24 -0000 1.3
+++ cluster-howto.xml 9 Jan 2004 23:36:34 -0000 1.4
@@ -234,7 +234,6 @@
<p>
The membership is established by all the tomcat instances are sending broadcast
messages
on the same multicast IP and port.
-
The TCP listen port, is the port where the session replication is received from
other members.
</p>
<p>
@@ -242,18 +241,25 @@
replication.
</p>
<p>
- One of the most important performance considerations is the synchronous versus
asynchronous replication
+ One of the most important performance considerations is the synchronous (pooled
or not pooled) versus asynchronous replication
mode. In a synchronous replication mode the request doesn't return until the
replicated session has been
sent over the wire and reinstantiated on all the other cluster nodes.
- Using synchronous mode potentially becomes a bottleneck, but is a must if you
cant have
- sticky sessions, what is recommended here is to increase the number of threads
that handle
+ There are two settings for synchronous replication. Pooled or not pooled.
+ Not pooled (ie replicationMode="synchronous") means that all the
replication request are sent over a single
+ socket.
+ Using synchronous mode potentially becomes a bottleneck,
+ You can overcome this bottleneck by setting replicationMode="pooled".
+ What is recommended here is to increase the number of threads that handle
incoming replication request. This is the tcpThreadCount property in the cluster
- section of server.xml.
+ section of server.xml. The pooled setting means that we are using multiple
sockets, hence increases the performance.
Asynchronous replication, should be used if you have sticky sessions until fail
over, then
your replicated data is not time crucial, but the request time is, at this time
leave the tcpThreadCount to
be number-of-nodes-1.
During async replication, the request is returned before the data has been
replicated. async replication yields shorter
request times, and synchronous replication guarantees the session to be
replicated before the request returns.
+</p>
+<p>
+ The parameter "replicationMode" has three different settings:
"pooled", "synchronous" and "asynchronous"
</p>
</section>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
