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:
- Configure the mid tier so that the resources necessary to service any request are already in memory
- Configure the mid tier so that if a resource is not in memory, it can be located and loaded quickly
- Configure the mid tier to issue longer cache directives to the browser to cache and re-use resources that are changed infrequently
- Configure the mid tier to load-balance effectively across an AR System server group (if you have a server group environment)
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.
Comments
Log in or register to comment.