[jboss-cvs] JBossAS SVN: r94317 - projects/docs/community/5/Performance_Tuning_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sun Oct 4 17:19:13 EDT 2009
Author: bstansberry at jboss.com
Date: 2009-10-04 17:19:12 -0400 (Sun, 04 Oct 2009)
New Revision: 94317
Modified:
projects/docs/community/5/Performance_Tuning_Guide/en-US/Performance_Tuning_Guide.xml
Log:
[JBAS-6299] Add cluster performance tuning section
Modified: projects/docs/community/5/Performance_Tuning_Guide/en-US/Performance_Tuning_Guide.xml
===================================================================
--- projects/docs/community/5/Performance_Tuning_Guide/en-US/Performance_Tuning_Guide.xml 2009-10-04 20:32:56 UTC (rev 94316)
+++ projects/docs/community/5/Performance_Tuning_Guide/en-US/Performance_Tuning_Guide.xml 2009-10-04 21:19:12 UTC (rev 94317)
@@ -366,6 +366,124 @@
</programlisting>
</section>
+
+ <section id="Clustering_Tuning">
+ <title>Clustering Tuning</title>
+ <para>If you are running your application in a cluster, particularly if if it involves high volume state replication around the cluster, there are a number of possible performance optimizations.
+ As with any performance optimizations, always load test your application before and after making changes to verify the change has the intended effect, and make one change at a time so it's
+ clear what change has what effect.</para>
+
+ <section>
+ <title>Ensuring Adequate Network Buffers</title>
+ <para>The standard clustered services in JBoss AS use UDP for intra-cluster communication, in order to take advantage of UDP-based IP multicast.
+ A downside to the use of UDP is some of the lossless transmission guarantees that are provided at the OS network level with TCP instead need to be implemented in Java code.
+ In order to achieve peak performance it is important to reduce the frequency of UDP packets being dropped in the network layers. A frequent cause of lost
+ packets is inadequately sized network buffers on the machines that are hosting the cluster nodes. The Enterprise Application Platform clustering code will <emphasis>request</emphasis>
+ adequately sized read and write buffers from the OS when it opens sockets, but most operating systems (Windows seems to be an exception) will only <emphasis>provide</emphasis> buffers
+ up to a maximum size. This maximum read and write buffer sizes are configurable at the OS level, and the default values are too low to allow peak performance. So, a simple tuning step
+ is to configure your OS to allow buffers up to the size JBoss AS clustering code will request.</para>
+
+ <para>The specific configuration steps needed to increase the maximum allowed buffer sizes are OS specific. See your OS documentation for instructions
+ on how to increase these. For Linux systems, maximum values for these buffers sizes that will survive machine restarts can be set by editing
+ the <literal>/etc/sysctl.conf</literal> file:</para>
+
+ <programlisting><![CDATA[# Allow a 25MB UDP receive buffer for JGroups
+net.core.rmem_max = 26214400
+# Allow a 1MB UDP send buffer for JGroups
+net.core.wmem_max = 1048576]]></programlisting>
+
+ </section>
+
+ <section>
+ <title>Isolating Intra-Cluster Traffic</title>
+ <para>If network resources are a bottleneck for your application, overall performance can be improved by isolating intra-cluster traffic from external request traffic.
+ This requires multiple NICs on your server machines, with request traffic coming in on one NIC and intra-cluster traffic using another. Once you
+ have the hardware set up, it is easy to tell JBoss AS nodes to use a different interface for the intra-cluster traffic:</para>
+
+ <screen>./run.sh -c all -b 10.0.0.104 -Djgroups.bind_addr=192.168.100.104</screen>
+
+ <para>In the above example, the <literal>-Djgroups.bind_addr</literal> setting tells the JBoss AS to run intra-cluster JGroups traffic
+ over the 192.168.100.104 interface, with <literal>-b</literal> specifying that all other traffic should use 10.0.0.104.</para>
+ </section>
+
+ <section>
+ <title>JGroups Message Bundling</title>
+ <para>The JGroups group communication library used by JBoss AS provides a feature known as "message bundling". Message
+ bundling is similar to nagling on a TCP socket -- small messages are queued before sending (for up to a configurable maximum time) until a configurable number
+ of bytes have accumulated, and then the queued messages are bundled and sent as one large message. Use of bundling can have significant performance benefits
+ for high-volume asynchronous session replication. However, it is not enabled by default, as bundling can add significant latency to other types of intra-cluster
+ traffic, particularly clustered Hibernate/JPA Second Level Cache traffic.</para>
+
+ <para>If your application uses high volume session replication (web sessions or EJB3 stateful session beans), you might be able to increase performance by configuring
+ the distributed caching layer to use a JGroups channel configured with message bundling enabled. This is done by editing the
+ <literal><JBoss_Home>/server/<your_configuration>/deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-jboss-beans.xml</literal> file. For example, for the cache used by default for
+ web sessions:</para>
+
+ <programlisting><![CDATA[. . .
+
+<!-- Standard cache used for web sessions -->
+<entry><key>standard-session-cache</key>
+<value>
+ <bean name="StandardSessionCacheConfig" class="org.jboss.cache.config.Configuration">
+
+ . . .
+
+ <!-- Replace standard 'udp' JGroups stack with
+ one that uses message bundling -->
+ <property name="multiplexerStack">udp-async</property>
+
+ . . .]]></programlisting>
+
+ <para>For FIELD granularity web sessions, in the same file the same change can be made to the cache configuration with the <literal>field-granularity-session-cache</literal> key.
+ For EJB3 stateful session beans, in the same file the same change can be made to the cache configuration with the <literal>sfsb-cache</literal> key.</para>
+ <note>
+ <para>Using the <literal>udp-async</literal> JGroups protocol stack for the session caches means an additional JGroups transport protocol will be used.
+ This means additional sockets will be opened compared to a standard Enterprise Application Platform installation.</para>
+ </note>
+ </section>
+
+ <section>
+ <title>Reducing the Volume of Web Session Replication</title>
+
+ <para>If your application is configured for web session replication, reducing the amount data being replicated can obviously improve performance.
+ This can be accomplished both by avoiding replication when a request hasn't actually updated the session
+ and by limiting replication to only the session data that has actually changed. See
+ the discussion of <emphasis role="bold">replication-trigger</emphasis> and
+ <emphasis role="bold">replication-granularity</emphasis> in <xref linkend="clustering-http-state"/> for
+ how to configure your application to limit the amount of data replicated.</para>
+ </section>
+
+ <section>
+ <title>Reducing the Volume of EJB3 Stateful Session Bean Replication</title>
+
+ <para>If your application is configured for EJB3 Stateful Session Bean replication, avoiding replication after bean requests that haven't modified
+ state can improve performance. This can be controlled by having your bean class implement the
+ <literal>org.jboss.ejb3.cache.Optimized</literal> interface. See <xref linkend="clustering-session-sfsb30"/>
+ for details.</para>
+ </section>
+
+ <section>
+ <title>Be Cautious with JPA/Hibernate Second Level Caching</title>
+ <para>JPA and Hibernate applications can often gain a performance boost by caching database data in the application server.
+ However, with a clustered application the decision of whether or not to cache data is more complex than in the non-clustered case.
+ This is because in a cluster, when database writes occur on one node, the caching layer needs to send a message to all
+ other nodes in the cluster telling them to update or invalidate their cache content. For types of data that
+ are frequently updated, the cost of the intra-cluster messages can outweigh the benefits of caching.</para>
+
+ <para>So, be sure to carefully load test your clustered application when deciding whether to store items
+ in the Hibernate Second Level Cache. Avoid the temptation to turn on caching for all entity types; instead
+ rank your entity types based on how infrequent writes of each type are and how likely it is that more
+ than one transaction will read a particular entity. Then enable caching for one type at a time,
+ testing for the performance impact.</para>
+
+ <para>Be doubly cautious about enabling caching of query result sets. When query caching is enabled, any
+ time there is a database write, the clustered cache needs to send <emphasis>two</emphasis> messages around
+ the cluster. These messages are used to ensure that any query results that may have been affected
+ by the write are invalidated out of the cache. These messages need to be sent whether
+ or not the entity type that has been written is itself cached. The cost of these messages can
+ easily offset the benefit of query result caching. So, again, be sure to test the effect of caching.</para>
+ </section>
+ </section>
<section>
<title>Other key configurations</title>
More information about the jboss-cvs-commits
mailing list