[jboss-cvs] JBossAS SVN: r75293 - projects/docs/community/5/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Jul 2 00:54:49 EDT 2008
Author: skittoli at redhat.com
Date: 2008-07-02 00:54:49 -0400 (Wed, 02 Jul 2008)
New Revision: 75293
Added:
projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
Modified:
projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml
projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Remoting.xml
Log:
added new files
Modified: projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml
===================================================================
--- projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml 2008-07-02 04:37:03 UTC (rev 75292)
+++ projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Administration_And_Configuration_Guide.xml 2008-07-02 04:54:49 UTC (rev 75293)
@@ -45,7 +45,10 @@
<title>Clustering Guide</title>
<xi:include href="Clustering_Guide.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
-
+ <part id="Perfomance" label="IV">
+ <title>Performance Tuning</title>
+ <xi:include href="Performance_Tuning.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </part>
<xi:include href="Alternative_DBs.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</book>
Modified: projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
===================================================================
--- projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2008-07-02 04:37:03 UTC (rev 75292)
+++ projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2008-07-02 04:54:49 UTC (rev 75293)
@@ -899,6 +899,43 @@
</para>
</note>
+<section>
+ <title>Why is FC needed on top of TCP ? TCP has its own flow control !</title>
+ <para>
+
+ The reason is group communication, where we essentially have to send group messages at the highest speed the slowest receiver can keep up with. Let's say we have a cluster {A,B,C,D}. D is slow (maybe overloaded), the rest is fast. When A sends a group message, it establishes TCP connections A-A (conceptually), A-B, A-C and A-D (if they don't yet exist). So let's say A sends 100 million messages to the cluster. Because TCP's flow control only applies to A-B, A-C and A-D, but not to A-{B,C,D}, where {B,C,D} is the group, it is possible that A, B and C receive the 100M, but D only received 1M messages. (BTW: this is also the reason why we need NAKACK, although TCP does its own retransmission).
+ </para>
+ <para>
+ Now JGroups has to buffer all messages in memory for the case when the original sender S dies and a node asks for retransmission of a message of S. Because all members buffer all messages they received, they need to purge stable messages (= messages seen by everyone) every now and then. This is done by the STABLE protocol, which can be configured to run the stability protocol round time based (e.g. every 50s) or size based (whenever 400K data has been received).
+ </para>
+ <para>
+ In the above case, the slow node D will prevent the group from purging messages above 1M, so every member will buffer 99M messages ! This in most cases leads to OOM exceptions. Note that - although the sliding window protocol in TCP will cause writes to block if the window is full - we assume in the above case that this is still much faster for A-B and A-C than for A-D.
+ </para>
+ <para>
+ So, in summary, we need to send messages at a rate the slowest receiver (D) can handle.
+ </para>
+</section>
+
+<section>
+ <title>So do I always need FC?</title>
+ <para>
+ This depends on how the application uses the JGroups channel. Referring to the example above, if there was something about the application that would naturally cause A to slow down its rate of sending because D wasn't keeping up, then FC would not be needed.
+ </para>
+ <para>
+ A good example of such an application is one that makes synchronous group RPC calls (typically using a JGroups RpcDispatcher.) By synchronous, we mean the thread that makes the call blocks waiting for responses from all the members of the group. In that kind of application, the threads on A that are making calls would block waiting for responses from D, thus naturally slowing the overall rate of calls.
+ </para>
+ <para>
+ A JBoss Cache cluster configured for REPL_SYNC is a good example of an application that makes synchronous group RPC calls. If a channel is only used for a cache configured for REPL_SYNC, we recommend you remove FC from its protocol stack.
+ </para>
+ <para>
+ And, of course, if your cluster only consists of two nodes, including FC in a TCP-based protocol stack is unnecessary. There is no group beyond the single peer-to-peer relationship, and TCP's internal flow control will handle that just fine.
+ </para>
+ <para>
+ Another case where FC may not be needed is for a channel used by a JBoss Cache configured for buddy replication and a single buddy. Such a channel will in many respects act like a two node cluster, where messages are only exchanged with one other node, the buddy. (There may be other messages related to data gravitation that go to all members, but in a properly engineered buddy replication use case these should be infrequent. But if you remove FC be sure to load test your application.)
+ </para>
+</section>
+
+
</section>
Added: projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
===================================================================
--- projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml (rev 0)
+++ projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2008-07-02 04:54:49 UTC (rev 75293)
@@ -0,0 +1,211 @@
+<?xml version='1.0'?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
+]>
+<chapter id="performance_tuning">
+ <title>JBoss AS 5 Performance Tuning</title>
+<section>
+ <title>Introduction</title>
+
+<para>
+ Developing applications and deploying them to an application server does not guarantee best performance without performance tuning of the applications and server.
+ Performance tuning involves ensuring your application does not consume resources unnecessarily while ensures best performance of the applications and application server.
+</para>
+<para>
+ Application design, hardware/network profile, operating system, application software development, testing and deployment all play a major role in performance tuning. A bottleneck in performance therefore could be caused by these factors not just your application. Recent studies show that most performance problems are the result of the applications not the middleware or the operating systems. This could be associated with the technological developments in computer software, hardware and networking which has increased their reliability.
+</para>
+<para>
+ Improvement of application design and undertaking performance review of your applications before implementation is vital to avoiding bottlenecks after implementation. To undertake a performance review you need to setup a test environment undertake and analyse the test results. To effectively undertake a review, you also need to identify peak application workload times and the difference from normal workload periods. Peak workload times could be during the day, week, certain periods of the month, quarter or year. In understanding peaks workloads it is advisable not to go by averages as the peaks may be much more than the averages calculated over a period. The system requirements are bound by the peaks in the workload not the averages. On undertaking tuning it is recommended to carry out a few more tests and tuning of your system until a satisfactory performance is achieved.
+</para>
+</section>
+
+<section>
+ <title>Instrumentation</title>
+<para>
+ Applications should always be instrumented for performance analysis. In most cases, it is evident that performance requirements and peak workloads examined before production are incorrect compared to during production. Without instrumentation of your applications, you will lack accurate tracking data. Workloads on your applications can also change over time, as the business size, models or environment changes.
+</para>
+<para>
+ Instrumentation in the past would have had to be embedded in the application. Today, there are many solutions for instrumentation that do not require developers to code. Commercial products, and the JBoss AOP framework can be used for just this purpose. You can also turn on call statistics in the containers, and Hibernate statistics. For more on this please refer to the AOP and Hibernate project pages.
+</para>
+
+</section>
+
+<section>
+ <title>Tuning the JVM</title>
+<para>
+ For java based applications, it is recommended to also be familiar with tuning of your Java Virtual Machine (JVM). Some key aspects of your JVM that need tweaking include managing out of memory exceptions, java heap settings and garbage collection. Please refer to the JDK 5 documentation on <ulink url="http://java.sun.com/j2se/1.5.0/docs/">http://java.sun.com/j2se/1.5.0/docs/</ulink> for further discussions on this.
+</para>
+</section>
+
+<section>
+ <title>Tuning JBoss Application Server</title>
+<para>
+ Before tuning the JBoss Application Server, please ensure that you are familiar with its components outlined in the introduction section of this book. You should also be familiar with any particular services your application may use on the application server and tune them to improve performance. It is also important to establish optimal database connections used by your applications and set these on the application server. This section discusses these among other JBoss Application Server performance tuning topics.
+</para>
+<section>
+ <title>Database Connection</title>
+<para>
+ Database connections can be costly to establish and manage. Applications that create new connections to the database with every transaction or query and then close that connection add a great deal of overhead. Having a very small connection pool will also throttle the applications as the JBoss application server by default queues the request for a default of 30,000 milliseconds (30 seconds) before cancellation and throwing an exception.
+</para>
+<para>
+ We recommend reliance on data source definitions you can setup in the deploy directory of the JBoss application server and utilizing the connection pool settings. Connection pooling in the JBoss application server allows you to easily monitor your connection usage from the JMX console to determine proper sizing. Your database management system may also shipped with tools that allow you to monitor connections.
+</para>
+<para>
+ Depending on the databases implemented, please ensure you create a data source file in the deploy directory of your configuration as shown below:
+
+<screen><JBoss_Home>/server/<your_configuration>/deploy/</screen>
+
+The filename should be in the following formats:
+
+<screen><yourdatabasename>-ds.xml</screen>
+</para>
+
+<note><title>Note</title>
+ <para>
+ Please note that the name of the file must end with <filename>-ds.xml</filename> in order for the JBoss application server to recognize it as a <emphasis>data source file</emphasis>. The Hypersonic database data source file for example is named <filename>hsqldb-ds.xml</filename>.
+</para>
+</note>
+
+<para>
+ The example below is a sample Hypersonic database data source file. Please note that this file contains more comments or descriptions for the respective tags. For a full view of this file, and its comments, please refer to the <filename>hsqldb-ds.xml</filename> in the <filename>deploy</filename> directory of your configuration.
+</para>
+
+<programlisting role="XML">...
+<datasources>
+ <local-tx-datasource>
+
+ <!-- The jndi name of the DataSource, it is prefixed with java:/ -->
+ <!-- Datasources are not available outside the virtual machine -->
+ <jndi-name>DefaultDS</jndi-name>
+
+ <!-- For server mode db, allowing other processes to use hsqldb over tcp.
+ This requires the org.jboss.jdbc.HypersonicDatabase mbean.
+ <connection-url>jdbc:hsqldb:hsql://${jboss.bind.address}:1701</connection-url>
+ -->
+ <!-- For totally in-memory db, not saved when jboss stops.
+ The org.jboss.jdbc.HypersonicDatabase mbean is required for proper db shutdown
+ <connection-url>jdbc:hsqldb:.</connection-url>
+ -->
+ <!-- For in-process persistent db, saved when jboss stops.
+ The org.jboss.jdbc.HypersonicDatabase mbean is required for proper db shutdown
+ -->
+ <connection-url>jdbc:hsqldb:${jboss.server.data.dir}${/}hypersonic${/}localDB</connection-url>
+
+ <!-- The driver class -->
+ <driver-class>org.hsqldb.jdbcDriver</driver-class>
+
+ <!-- The login and password. Do not enter plain text for production databases. Please see Security section for more information -->
+ <user-name>sa</user-name>
+ <password></password>
+
+ <!--example of how to specify class that determines if exception means connection should be destroyed-->
+ <!--exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.DummyExceptionSorter</exception-sorter-class-name-->
+
+ <!-- this will be run before a managed connection is removed from the pool for use by a client-->
+ <!--<check-valid-connection-sql>select * from something</check-valid-connection-sql> -->
+
+ <!-- The minimum database connections managed in a pool/sub-pool. Pools are lazily constructed on first use -->
+ <min-pool-size>5</min-pool-size>
+
+ <!-- The maximum database connections managed in a pool/sub-pool -->
+ <max-pool-size>20</max-pool-size>
+
+ <!-- The time before an unused connection is destroyed -->
+ <!-- NOTE: This is the check period. It will be destroyed somewhere between 1x and 2x this timeout after last use -->
+ <!-- TEMPORARY FIX! - Disable idle connection removal, HSQLDB has a problem with not reaping threads on closed connections -->
+ <idle-timeout-minutes>0</idle-timeout-minutes>
+
+ <!-- sql to call when connection is created
+ <new-connection-sql>some arbitrary sql</new-connection-sql>
+ -->
+
+ <!-- sql to call on an existing pooled connection when it is obtained from pool
+ <check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>
+ -->
+
+ <!-- example of how to specify a class that determines a connection is valid before it is handed out from the pool
+ <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.DummyValidConnectionChecker</valid-connection-checker-class-name>
+ -->
+
+ <!-- Whether to check all statements are closed when the connection is returned to the pool,
+ this is a debugging feature that should be turned off in production -->
+ <track-statements/>
+
+ <!-- Use the getConnection(user, pw) for logins
+ <application-managed-security/>
+ -->
+
+ <!-- Use the security domain defined in conf/login-config.xml -->
+ <security-domain>HsqlDbRealm</security-domain>
+
+ <!-- Use the security domain defined in conf/login-config.xml or the
+ getConnection(user, pw) for logins. The security domain takes precedence.
+ <security-domain-and-application>HsqlDbRealm</security-domain-and-application>
+ -->
+
+ <!-- HSQL DB benefits from prepared statement caching which stores recent prepared statements for future use. The prepared-statement-cache-size indicates the number of prepared statements to store in the cache. -->
+ <prepared-statement-cache-size>32</prepared-statement-cache-size>
+
+ <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
+ <metadata>
+ <type-mapping>Hypersonic SQL</type-mapping>
+ </metadata>
+
+ <!-- When using in-process (standalone) mode -->
+ <depends>jboss:service=Hypersonic,database=localDB</depends>
+ <!-- Uncomment when using hsqldb in server mode
+ <depends>jboss:service=Hypersonic</depends>
+ -->
+ </local-tx-datasource>
+
+ <!-- Uncomment if you want hsqldb accessed over tcp (server mode)
+ <mbean code="org.jboss.jdbc.HypersonicDatabase"
+ name="jboss:service=Hypersonic">
+ <attribute name="Port">1701</attribute>
+ <attribute name="BindAddress">${jboss.bind.address}</attribute>
+ <attribute name="Silent">true</attribute>
+ <attribute name="Database">default</attribute>
+ <attribute name="Trace">false</attribute>
+ <attribute name="No_system_exit">true</attribute>
+ </mbean>
+ -->
+
+ <!-- For hsqldb accessed from jboss only, in-process (standalone) mode -->
+ <mbean code="org.jboss.jdbc.HypersonicDatabase"
+ name="jboss:service=Hypersonic,database=localDB">
+ <attribute name="Database">localDB</attribute>
+ <attribute name="InProcessMode">true</attribute>
+</mbean>
+
+</datasources>
+</programlisting>
+
+ </section>
+
+ <section>
+ <title>Other key configurations</title>
+<para>
+ Other key configurations required for performance tuning of your application server include the <filename><JBoss_Home>/server/<your_configuration>/deployers/jbossweb.deployer/server.xml</filename> file that sets your HTTP requests pool.
+</para>
+<para>
+ JBoss AS 5 has a robust thread pooling, that should be sized appropriately.
+ The server has a <filename>jboss-service.xml</filename> file in the <filename><JBoss_Home>/server/<your_configuration>/conf</filename> directory that defines the system thread pool.
+ There is a setting that defines the behavior if there isn't a thread available in the pool for execution. The default is to allow the calling thread to execute the task. You can monitor the queue depth of the system thread pool through the JMX Console, and determine from that if you need to make the pool larger.
+</para>
+
+<para>
+ The <literal>default</literal> configuration is appropriate for development, but not necessarily for a production environment. In the default configuration, console logging is enabled. Console logging is ideal for development, especially within the IDE, as you get all the log messages to show in the IDE console view.
+ In a production environment, console logging is very expensive and is not recommended.
+ Turn down the verbosity level of logging if its not necessary. Please note that the less you log, the less I/O will be generated, and the better the overall throughput will be.
+</para>
+
+<para>
+ Other performance tuning aspects include Caching, Clustering and Replication which are discussed in the respective Chapters in this book.
+</para>
+
+</section>
+
+</section>
+
+
+
+</chapter>
Property changes on: projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
___________________________________________________________________
Name: svn:executable
+ *
Modified: projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Remoting.xml
===================================================================
--- projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Remoting.xml 2008-07-02 04:37:03 UTC (rev 75292)
+++ projects/docs/community/5/Administration_And_Configuration_Guide/en-US/Remoting.xml 2008-07-02 04:54:49 UTC (rev 75293)
@@ -158,7 +158,6 @@
As indicated earlier in this chapter, JBoss Remoting manages synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. You can configure JBoss Remoting through the JBoss Messaging service configuration file <filename>JBOSS_HOME/server/<your_configuration>/deploy/messaging/remoting-service.xml</filename>.
</para>
- <para>
-
- </para>
+</section>
+
</chapter>
\ No newline at end of file
More information about the jboss-cvs-commits
mailing list