[jboss-cvs] JBossAS SVN: r100328 - projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Feb 3 03:01:49 EST 2010
Author: laubai
Date: 2010-02-03 03:01:49 -0500 (Wed, 03 Feb 2010)
New Revision: 100328
Modified:
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
Log:
Partial edit of Perf_Tuning.xml.
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2010-02-03 07:42:29 UTC (rev 100327)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Performance_Tuning.xml 2010-02-03 08:01:49 UTC (rev 100328)
@@ -224,107 +224,120 @@
Java 6 includes new tools that help monitor Java applications. <application>Jmap</application> can generate a heap dump file (<ulink url="http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html">http://java.sun.com/javase/6/docs/technotes/tools/share/jmap.html</ulink>) that can easily be read by the Eclipse Memory Analyzer tool (<ulink url="http://www.eclipse.org/mat/">http://www.eclipse.org/mat/</ulink>). The <application>jstat</application> tool (<ulink url="http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html">http://java.sun.com/javase/6/docs/technotes/tools/share/jstat.html</ulink>) can help give you a precise picture of your permanent memory space and the other segments on the Java memory heap.
</para>
</note>
-<!--hajime-->
+
<section id="VFS_Tuning">
<title>VFS Tuning</title>
<para>
When looking for various tuning options for the VFS (Virtual File System), most of the information that exists can be found in <classname>VFSUtils</classname> class.
Its string constants point us to different possible system property settings we can use to configure VFS behavior:</para>
- <itemizedlist>
- <listitem>
- <para>
- <property>jboss.vfs.forceCopy</property>
- </para>
- <para>
- This defines how nested jars should be handled. If forceCopy equals true (the default), we create a temporary copy of the nested jar, and re-wire VFS accordingly. If forceCopy equals false, we handle nested jars in-memory, which doesn't create temporary copy, but is more memory consuming.
- </para>
-<!-- <para>
- If the <property>useCopyJarHandler</property> property is used as part of URI query, you can configure force-copy at runtime, per URI root (if it doesn't already exist).
- </para>-->
- </listitem>
- <listitem>
- <para>
- <property>jboss.vfs.forceVfsJar</property> has the options true and false, with the default being false.
- </para>
- <para>
- By setting this property to true, you can implement the old JAR handling. Set to false by default, old JAR handling was deprecated in favor of new ZIP handling code.
- </para>
- </listitem>
- <listitem>
- <para>
- <property>jboss.vfs.forceNoReaper</property> has the options true and false, with the default being false.
- </para>
- <para>
- To gain a bit on performance, we close JAR files asynchronously via the separate reaper thread. If you wish to close JAR files synchronously, you can force no usage of the reaper thread. This can also be defined using the URI query and the <literal>noReaper</literal> query section.
- </para>
- </listitem>
- <listitem>
- <para>
- <property>jboss.vfs.forceCaseSensitive</property> has the options true and false, with the default being false.
- </para>
- <para>
- With this enabled you can force differentiation between lower and upper cased file paths.
- </para>
- </listitem>
- <listitem>
- <para>
- <property>jboss.vfs.optimizeForMemory</property> has the options true and false, with the default being false.
- </para>
- <para>
- With this enabled we re-order in-memory JAR handling, to gain on memory consumption.
- </para>
- </listitem>
- <listitem>
- <para>
- The <classname>jboss.vfs.cache</classname> (<classname>org.jboss.virtual.spi.cache.helpers.NoopVFSCache</classname>) class can be defined in order to re-use existing temporary files (in order not to re-do all unpacking and wiring). The VFS registry will use the defining of this class to keep its existing VFS roots.
- </para>
- <para>
- Every <methodname>VirtualFile</methodname> lookup from the VFS class uses this <literal>singleton</literal> cache instance to check for an existing matching cache entry. By matching we also consider any existing <emphasis>ancestor</emphasis> from which you can use exact <methodname>VirtualFile</methodname> instance.
- </para>
- </listitem>
- </itemizedlist>
+ <variablelist>
+ <varlistentry>
+ <term><varname>jboss.vfs.forceCopy</varname></term>
+ <listitem>
+ <para>
+ Defines how nested JARs are handled. If <literal>true</literal> (the default), a temporary copy of the nested JAR is created and the VFS is re-wired accordingly. If <literal>false</literal>, nested JARs are handled in-memory. No temporary copy is created, but this option consumes more memory.
+ </para>
+ <!-- <para>
+ If the <property>useCopyJarHandler</property> property is used as part of URI query, you can configure force-copy at runtime, per URI root (if it doesn't already exist).
+ </para>-->
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>jboss.vfs.forceVfsJar</varname></term>
+ <listitem>
+ <para>
+ When <literal>true</literal>, implements old JAR handling. This value is false by default. Old JAR handling was deprecated in favor of new ZIP handling code.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>jboss.vfs.forceNoReaper</varname></term>
+ <listitem>
+ <para>
+ Set to <literal>false</literal> by default. This specifies that JAR files are closed asynchronously by a separate reaper thread, which can improve performance. To close JAR files synchronously, force no usage of the reaper thread by setting this to <literal>true</literal>. This can also be defined using the URI query and the <literal>noReaper</literal> query section.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>jboss.vfs.forceCaseSensitive</varname></term>
+ <listitem>
+ <para>
+ When <literal>true</literal>, forces differentiation between lower and upper case file paths. The default value is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>jboss.vfs.optimizeForMemory</varname></term>
+ <listitem>
+ <para>
+ When <literal>true</literal>, re-orders in-memory JAR handling to reduce memory consumption. The default value is <literal>false</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>jboss.vfs.cache</varname></term>
+ <listitem>
+ <para>
+ Define this class (<classname>org.jboss.virtual.spi.cache.helpers.NoopVFSCache</classname>) to reuse existing temporary files so that unpacking and wiring does not to be repeated. The VFS registry uses this class definition to keep its existing VFS roots. Every <methodname>VirtualFile</methodname> lookup from the VFS class uses this singleton cache instance to check for an existing matching cache entry. Matching also considers any existing ancestor that lets you use the same <methodname>VirtualFile</methodname> instance.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<section>
<title>VFS Cache Tuning</title>
<para>
-As described before, VFS cache holds VFS roots, from which any VirtualFile lookup can access existing VirtualFile instances.
-This is a sepcially useful in the case of temporary files (created from nested JARs), meaning you don't have to do multiple unpackings for nested JAR file related resources.</para>
+ The VFS cache holds VFS roots, from which any <methodname>VirtualFile</methodname> lookup can access existing <methodname>VirtualFile</methodname> instances. This is a especially useful in the case of temporary files (created from nested JARs), since multiple unpackings for nested JAR file related resources are not required.</para>
+ <para>
+ By default there is no caching in VFS, since <classname>org.jboss.virtual.spi.cache.helpers.NoopVFSCache</classname> is used. You can provide your own cache implementation or choose from existing VFS implementations.
+ </para>
+ <para>
+ The cache implementations available as part of the <literal>org.jboss.virtual.plugins.cache</literal> package are:
+ </para>
+<variablelist>
+ <varlistentry>
+ <term><classname>SoftRefVFSCache</classname></term>
+ <listitem>
+ <para>
+ Uses soft reference as a map's entry value.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><classname>WeakRefVFSCache</classname></term>
+ <listitem>
+ <para>
+ Uses weak reference as a map's entry value.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><classname>TimedVFSCache</classname></term>
+ <listitem>
+ <para>
+ Evicts cache entries after the <varname>defaultLifetime</varname>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><classname>LRUVFSCache</classname></term>
+ <listitem>
+ <para>
+ Evicts cache entries based on LRU, keeping minimum and maximum entries.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><classname>CombinedVFSCache</classname></term>
+ <listitem>
+ <para>
+ Holds few permanent roots. Any new root is cached in its <varname>realCache</varname> property.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
<para>
-By default in VFS there is no caching involved as <classname>org.jboss.virtual.spi.cache.helpers.NoopVFSCache</classname> is used.
-But you can provide your own implementation or choose from existing VFS implementations.</para>
-
-<para>
-Cache implementations from the <literal>org.jboss.virtual.plugins.cache</literal> package are:</para>
-<itemizedlist>
- <listitem>
- <para>
- <classname>SoftRefVFSCache</classname>: uses soft reference as map's entry value.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>WeakRefVFSCache</classname>: uses weak reference as map's entry value.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>TimedVFSCache</classname>: evicts cache entries after defaultLifetime.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>LRUVFSCache</classname>: evicts cache entries based on LRU, keeping min and max entries.
- </para>
- </listitem>
- <listitem>
- <para>
- <classname>CombinedVFSCache</classname>: holds few permanent roots, any other new root is cached in its realCache property.
- </para>
- </listitem>
-</itemizedlist>
-<para>
- In the JBoss Enterprise Web Platform we use <classname>CombinedVFSCache</classname> as we know which are our permanent roots to watch and keep.
- This is how it's configured in MC's bean configuration file.
+ By default, JBoss Enterprise Web Platform uses <classname>CombinedVFSCache</classname>. The cache type is configured in JBoss Microcontainer's bean configuration file, <filename>$JBOSS_HOME/server/$PROFILE/conf/bootstrap/vfs.xml</filename>, like so:
</para>
<programlisting><![CDATA[
<bean name="VFSCache">
@@ -359,13 +372,12 @@
</bean>]]>
</programlisting>
<para>
-Any new custom VFS root (for example, an additional <filename>deploy</filename> directory) should be added to this configuration.
+ Any new custom VFS root (for example, an additional <filename>deploy</filename> directory) should be added to this configuration.
</para>
</section>
<section>
<title>Annotation Scanning Tuning</title>
- <para>
-There are currently three ways to limit resources scanning.</para>
+ <para>There are currently three ways to limit resources scanning:</para>
<itemizedlist>
<listitem>
<para>
@@ -374,17 +386,18 @@
</listitem>
<listitem>
<para>
- Add a new deployment filter to <classname>GenScanDeployer</classname> bean in <filename>deployers/metadata-deployer-jboss-beans</filename>.
+ Add a new deployment filter to <classname>GenScanDeployer</classname> bean in <filename>deployers/metadata-deployer-jboss-beans.xml</filename>.
</para>
</listitem>
<listitem>
<para>
- Modify <classname>JBossCustomDeployDUFilter</classname> in <filename>deployers/metadata-deployer-jboss-beans</filename>.
+ Modify <classname>JBossCustomDeployDUFilter</classname> in <filename>deployers/metadata-deployer-jboss-beans.xml</filename>.
</para>
</listitem>
-</itemizedlist>
-<para>
-ScanningMetaData can come from the <filename>jboss-scanning.xml</filename> file placed in <filename>META-INF</filename> directory. This is a simple example of this file:</para>
+</itemizedlist><!--hajime-->
+ <para>
+ <classname>ScanningMetaData</classname> can come from the <filename>jboss-scanning.xml</filename> file placed in your <filename>META-INF</filename> directory. This is a simple example of this file:
+ </para>
<programlisting><![CDATA[
<scanning xmlns="urn:jboss:scanning:1.0">
<path name="myejbs.jar">
More information about the jboss-cvs-commits
mailing list