<commit_before><!--
    Copyright (C) 2006 Orbeon, Inc.

    The Orbeon documentation is not distributed under the LGPL license. Use of the documentation is
    subject to the following terms:

    * Conversion to other formats is allowed, but the actual content may not be altered or edited
      in any way.

    * You may create printed copies for your own personal use.

    * For all other uses, such as selling printed copies or using (parts of) the manual in another
      publication, prior written agreement from Orbeon, Inc. is required.

    Please contact Orbeon at <EMAIL> for more information.
-->
<document xmlns:p="http://www.orbeon.com/oxf/pipeline"
    xmlns:xforms="http://www.w3.org/2002/xforms">
    <header>
        <title>Performance and Tuning</title>
    </header>
    <body>
        <section>
            <title>Tuning the Java Virtual Machine (JVM)</title>
            <section>
                <title>Set <code>-Xms</code> and <code>-Xmx</code> to the same value</title>
                <p>
                    The heap is a section of memory used by the JVM to store Java objects. You can
                    set constraints on the size of the heap with two parameters passed to the JVM at
                    startup: <code>-Xms</code> sets the initial size of the heap and
                    <code>-Xmx</code> sets the maximum size of the heap. If you set those two
                    parameters to different values, say 512MB and 1GB, you tell the JVM to start
                    with a heap size of 512MB and increase the size up to 1GB "as necessary". In
                    this case, the JVM has to balance two conflicting constraints: not request too
                    much memory from the operating system (getting too fast to 1GB), and not request
                    too little as it would increase the amount of time the to spends on garbage
                    collection which would will reduce the performance of your application.
                </p>
                <p>
                    Asking the JVM to balance memory usage and performance by setting different
                    values for <code>-Xms</code> and <code>-Xmx</code> is very reasonable for
                    desktop applications where a number of applications are running and competing
                    for resources, in particular memory. In a server environment, you often have one
                    or two major applications running on the server, like the JVM for your
                    application serer and maybe a database server. In this situation you have more
                    control over how much memory can be used by each application, and we recommend
                    you set both <code>-Xms</code> and <code>-Xmx</code> to the same value.
                </p>
            </section>
            <section>
                <title>Allocate a large heap but don't cause swapping</title>
                <p>
                    The larger the heap, the faster your application will be get. This for two
                    reasons: first, the JVM garbage collector works more efficiently with a larger
                    heap, and second, this enables you to increase the size of the OPS cache (more
                    on this later) which will also improve the performance of your application.
                    However, don't use a heap size so large that it would cause swapping, as this
                    would then drastically reduce the performance of your application.
                </p>
                <p>
                    We recommend that you first set the heap size based on how much memory the
                    server has and what other major applications are running. Say you have 2GB of
                    physical memory, and no other major application: then you could set the heap to
                    1.5GB, which leaves 512MB to the operating system and minor applications. Say
                    you have 4GB of physical memory and also a database running on the same server,
                    then you can set the heap size to 2GB, assign 1.5GB to the database server, and
                    leanve 512MB to the operating and minor applications.
                </p>
                <p>
                    Then, with a "reasonable" setting in place, monitor the server under normal load
                    and look if the machine is swapping or if on the contrary the operating system
                    is reporting a lot of available memory. In the first case, reduce the heap
                    size. In the second, increase it.
                </p>
            </section>
        </section>
        <section>
            <title>Tuning the application server</title>
            <section>
                <title>WebLogic: Disable automatic redeployment</title>
                <p>
                    WebLogic can be configured to check on a regular basis if the files of your
                    application have changed on disk, and redeploy the application if they did.
                    Redeploying at application server level is useful when you change the JAR files
                    or some of the underlying configuration files, like the web.xml. As checking if
                    files have changed is incredibly time consuming with WebLogic, and as you are
                    pretty unlikely to change any of those files on a regular basis, we recommend
                    you disable the automatic web application redeployment feature, which is
                    enabled by default.
                </p>
                <p>
                    To do this, after you have installed your OPS application, stop WebLogic, and
                    open the <code>config.xml</code> file in an editor. Look for the
                    <code>&lt;WebAppComponent Name="orbeon"></code> element and add the attribute:
                    <code>ServletReloadCheckSecs="-1"</code>.
                </p>
            </section>
            <section>
                <title>All application servers: Disable DNS lookup</title>
                <p>
                    You can configure your application server to perform a DNS lookup for every HTTP
                    request. The server always know the IP address of the machine where the HTTP
                    request originated. However, to get the name, the application server needs to
                    send a DNS lookup query to the DNS server. In most cases, performing this query
                    only has a negligible impact on performance. However, the request can take a
                    significant amount of time in certain cases where the network from which the
                    request originated is badly configured. In most case, the application server is
                    doing DNS lookups for "aesthetic reasons": that is to able to in include in the
                    logs the name of the client's machines, instead of their IP address (note that
                    web analysis tools can usually do this reverse DNS lookup much more efficiently
                    when analysing log files subsequently, typically on a daily basis). So we
                    recommend you change the configuration of your application server to disable DNS
                    lookup, which is in general enabled by default.
                </p>
                <p>
                    On Tomcat 5 (<a
                    href="http://tomcat.apache.org/tomcat-5.0-doc/config/http.html">external
                    documentation</a>), look for the <code>enableLookups</code> attribute on the
                    <code>&lt;Connector></code> element and set it to <code>false</code>. If the
                    attribute is not present, add it and set it to <code>false</code> (the default
                    value is <code>true</code>).
                </p>
            </section>
        </section>
        <section>
            <title>Tunning OPS</title>
            <a name="ops-cache"/>
            <section>
                <title>Tune the OPS cache size</title>
                <p>
                    One way to increase the performance of your application is to increase the size
                    of the OPS cache. You setup the size of the OPS cache with the <a
                    href="reference-properties#cache-size">oxf.cache.size</a> property. Due to
                    limitations of the JVM, you cannot set the size of the OPS cache in MB. Instead,
                    the value you specify the maximum number of objects that OPS can store in cache.
                    As the size of each object stored in cache is different and the average size of
                    those objects can change widely depending on your application, we can't give you<commit_msg>Added note about gzip compression.<commit_after><!--
    Copyright (C) 2006 Orbeon, Inc.

    The Orbeon documentation is not distributed under the LGPL license. Use of the documentation is
    subject to the following terms:

    * Conversion to other formats is allowed, but the actual content may not be altered or edited
      in any way.

    * You may create printed copies for your own personal use.

    * For all other uses, such as selling printed copies or using (parts of) the manual in another
      publication, prior written agreement from Orbeon, Inc. is required.

    Please contact Orbeon at <EMAIL> for more information.
-->
<document xmlns:p="http://www.orbeon.com/oxf/pipeline"
    xmlns:xforms="http://www.w3.org/2002/xforms">
    <header>
        <title>Performance and Tuning</title>
    </header>
    <body>
        <section>
            <title>Tuning the Java Virtual Machine (JVM)</title>
            <section>
                <title>Set <code>-Xms</code> and <code>-Xmx</code> to the same value</title>
                <p>
                    The heap is a section of memory used by the JVM to store Java objects. You can
                    set constraints on the size of the heap with two parameters passed to the JVM at
                    startup: <code>-Xms</code> sets the initial size of the heap and
                    <code>-Xmx</code> sets the maximum size of the heap. If you set those two
                    parameters to different values, say 512MB and 1GB, you tell the JVM to start
                    with a heap size of 512MB and increase the size up to 1GB "as necessary". In
                    this case, the JVM has to balance two conflicting constraints: not request too
                    much memory from the operating system (getting too fast to 1GB), and not request
                    too little as it would increase the amount of time the to spends on garbage
                    collection which would will reduce the performance of your application.
                </p>
                <p>
                    Asking the JVM to balance memory usage and performance by setting different
                    values for <code>-Xms</code> and <code>-Xmx</code> is very reasonable for
                    desktop applications where a number of applications are running and competing
                    for resources, in particular memory. In a server environment, you often have one
                    or two major applications running on the server, like the JVM for your
                    application serer and maybe a database server. In this situation you have more
                    control over how much memory can be used by each application, and we recommend
                    you set both <code>-Xms</code> and <code>-Xmx</code> to the same value.
                </p>
            </section>
            <section>
                <title>Allocate a large heap but don't cause swapping</title>
                <p>
                    The larger the heap, the faster your application will be get. This for two
                    reasons: first, the JVM garbage collector works more efficiently with a larger
                    heap, and second, this enables you to increase the size of the OPS cache (more
                    on this later) which will also improve the performance of your application.
                    However, don't use a heap size so large that it would cause swapping, as this
                    would then drastically reduce the performance of your application.
                </p>
                <p>
                    We recommend that you first set the heap size based on how much memory the
                    server has and what other major applications are running. Say you have 2GB of
                    physical memory, and no other major application: then you could set the heap to
                    1.5GB, which leaves 512MB to the operating system and minor applications. Say
                    you have 4GB of physical memory and also a database running on the same server,
                    then you can set the heap size to 2GB, assign 1.5GB to the database server, and
                    leanve 512MB to the operating and minor applications.
                </p>
                <p>
                    Then, with a "reasonable" setting in place, monitor the server under normal load
                    and look if the machine is swapping or if on the contrary the operating system
                    is reporting a lot of available memory. In the first case, reduce the heap
                    size. In the second, increase it.
                </p>
            </section>
        </section>
        <section>
            <title>Tuning the application server</title>
            <section>
                <title>WebLogic: Disable automatic redeployment</title>
                <p>
                    WebLogic can be configured to check on a regular basis if the files of your
                    application have changed on disk, and redeploy the application if they did.
                    Redeploying at application server level is useful when you change the JAR files
                    or some of the underlying configuration files, like the web.xml. As checking if
                    files have changed is incredibly time consuming with WebLogic, and as you are
                    pretty unlikely to change any of those files on a regular basis, we recommend
                    you disable the automatic web application redeployment feature, which is
                    enabled by default.
                </p>
                <p>
                    To do this, after you have installed your OPS application, stop WebLogic, and
                    open the <code>config.xml</code> file in an editor. Look for the
                    <code>&lt;WebAppComponent Name="orbeon"></code> element and add the attribute:
                    <code>ServletReloadCheckSecs="-1"</code>.
                </p>
            </section>
            <section>
                <title>All application servers: Disable DNS lookup</title>
                <p>
                    You can configure your application server to perform a DNS lookup for every HTTP
                    request. The server always know the IP address of the machine where the HTTP
                    request originated. However, to get the name, the application server needs to
                    send a DNS lookup query to the DNS server. In most cases, performing this query
                    only has a negligible impact on performance. However, the request can take a
                    significant amount of time in certain cases where the network from which the
                    request originated is badly configured. In most case, the application server is
                    doing DNS lookups for "aesthetic reasons": that is to able to in include in the
                    logs the name of the client's machines, instead of their IP address (note that
                    web analysis tools can usually do this reverse DNS lookup much more efficiently
                    when analysing log files subsequently, typically on a daily basis). So we
                    recommend you change the configuration of your application server to disable DNS
                    lookup, which is in general enabled by default.
                </p>
                <p>
                    On Tomcat 5 (<a
                    href="http://tomcat.apache.org/tomcat-5.0-doc/config/http.html">external
                    documentation</a>), look for the <code>enableLookups</code> attribute on the
                    <code>&lt;Connector></code> element and set it to <code>false</code>. If the
                    attribute is not present, add it and set it to <code>false</code> (the default
                    value is <code>true</code>).
                </p>
            </section>
            <a name="gzip"/>
            <section>
                <title>Enable gzip compression for generated text content</title>
                <p>
                    HTML and XML content usually compresses extremely well using gzip. You can obtain sizes for the
                    content sent by the server to the web browser that are up to 10 times smaller. A very complex XForms
                    page taking 100 KB, for example, may end up taking only about 10 KB. This means that the data will
                    reach the web browser up to 10 times faster than without gzip compression.
                </p>
                <p>
                    Most web and application servers support gzip compression. For example, Tomcat 5 supports the
                    attribute <code>gzip</code> on the <code>&lt;Connector></code> element. For more information,
                    please visit the <a href="http://tomcat.apache.org/tomcat-5.5-doc/config/http.html">Tomcat HTTP
                    connector documentation</a>.
                </p>
            </section>
        </section>
        <section>
            <title>Tunning OPS</title>
            <a name="ops-cache"/>
            <section>
                <title>Tune the OPS cache size</title>
                <p>
                    One way to increase the performance of your application is to increase the size
                    of the OPS cache. You setup the size of the OPS cache with the <a
                    href="reference-properties#cache-size">oxf.cache.size</a> property. Due to
                    limitations of the JVM, you cannot set the size of the OPS cache in MB. Instead,
                    the value you specify the maximum number of objects that OPS can store in cache.
                    As the size of each object stored in cache is different and the average size of
                    those objects can change widely depending on your application, we can't give you
{'fraction_non_alphanumeric': 0.05076816756153314, 'fraction_numerical': 0.004359151560257297, 'mean_word_length': 1.6847438276009705, 'pattern_counts': {'":': 2, '<': 206, '<?xml version=': 0, '>': 211, 'https://': 0, 'lorem ipsum': 0, 'www.': 4, 'xml': 8}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3394808', 'n_tokens_mistral': 4315, 'n_tokens_neox': 3979, 'n_words': 2220}