This documentation supports the 20.02 version of Remedy Deployment.
To view an earlier version, select the version from the Product version menu.

Fine tuning the mid tier web application

This section discusses fine tuning the mid tier web application layer to achieve a performance optimization that is specific to your deployment environment. The following scenarios are discussed:

The mid tier web application stack than compiling a JSP because the BMC Remedy AR System development paradigm is quite different from the web development paradigm.

The compiling process of BMC Remedy AR System definitions into DHTML (HTML/JavaScript) prior to user access in the mid tier is referred to as prebuilding, precaching, or preloading of AR System forms. After a form is built, it is also loaded and cached in memory inside the mid tier web application unless a resource limitation is preventing this from happening.

Note

The prebuilding of a form requires the prebuilding of all its subparts, such as active links and fields. This process is distinct from browser caching.

Compiling of form definitions into DHTML is CPU intensive. So, when a browser user accesses a BMC Remedy AR System form that the mid tier has not yet prebuilt into DHTML, it takes longer to open the form because the mid tier must compile the definition before it can service the browser request. This service time can be as long as 1 minute, depending on the complexity of the form definition. However, if the form is already prebuilt and cached in memory, the response time is generally less than 10 milliseconds.

To achieve optimal browser time, the mid tier relies heavily on prebuilding forms and caching the resulting transformations in memory. Because memory availability is finite, the mid tier also has a serialization process for writing the objects that are not currently needed to disk. This frees up memory. See JVM heap size setting to learn about leveraging more memory for the mid tier cache.

Lastly, every browser has a caching mechanism to cache or write URL response contents to disk. Subsequent requests for the same URL resources are read from disk rather than via submitting HTTP requests if the cached contents on disk are still valid. The validity of the cached resources are dictated by the browser cache directives issued by the web application which provided the content for each URL.

Was this page helpful? Yes No Submitting... Thank you

Comments