This section covers the following topics:
Site Studio web sites are dynamic web sites that allow for the quick delivery of different forms of content within each different page. But there are some portions of Site Studio that can be customized to allow for even better performance.
Some of the web sites you create and maintain may not be used often. In these cases, it would be easier to keep the server from loading these sites into memory until they are actually requested, improving the server performance through memory management.
The sites you want to load only when requested can be marked as such in the Administrator, using on-demand management you can select which sites load when the server boots, and those that load when requested.
When a site has been requested, it then stays in memory as the other sites.
For more information on On-Demand web sites, see the Oracle WebCenter Content Administrator and Manager's Guide for Site Studio.
Contributor can occasionally take some time to load if there are a large number of elements in a contribution region. This is to be expected. There are some configuration flags in Site Studio that can be set to allow for faster loading of Contributor by using on-demand editors.
This section covers the following topics:
Site Studio uses a large number of configuration flags for different actions. Since there are so many flags, only those used in the most common instances will be described.
Contributor loads an editor for each element in a contribution region, whether or not it displays on the page. When there are a large number of elements, this can cause much longer loading and waiting times for the contributors.
There are flags that can be modified to allow for the use of on-demand editors in Contributor. The on-demand editor shows a preview of the data contained in the element, but the editor will not load until requested.
This configuration flag is used to enable the on demand editors in Contributor only when there are a certain number of elements to load. When you set this flag to a certain number n, the elements will become on demand elements when there are n+1 elements in the contribution region.
Integer
5
There are substantial portions of the code in Contributor that are based on JavaScript and CSS. This code can be optimized.
Optimized Contributor source code is JavaScript and CSS code that has been compressed and consolidated. Optimized source code improves the Contributor application's load time and execution speed in the browser. By default, Site Studio is initially configured to use un-optimized source code for debugging and configuration purposes.
This section includes the following topics:
The build process requires a JDK for Java that implements the 1.5 or greater specifications.
It is important to note that the build system will only work correctly by default if the tools directory resides just within the root directory of the Contributor application. In most cases, the tools directory will reside in the following location:
CONTENT_SERVER_INSTALL_DIR\weblayout\resources\wcm\tools
Note:
If the computer is configured to use a default Java Runtime Environment with a version less than 1.5, the invocation of the compression module in the WCM.Compress function in the build.js script should be changed to reference a compliant runtime environment. Specifically, the first parameter to the runCommand function should be changed from java to a full path reference to the java executable version 1.5 or greater.All the logic to build optimized Contributor source code is located in build.js, written in JavaScript. The build process uses Rhino , a JavaScript interpreter, to execute the build script to create optimized Contributor source code. The build.js script file is located in following directory:
\tools\optimize\build.js
The build process first makes a duplicate copy of the un-optimized code. By default, the destination directory will be called 'wcm_min' and will reside just outside the root directory of the Contributor application in the following location:
CONTENT_SERVER_INSTALL_DIR\weblayout\resources\wcm_min
After that, the build process manipulates the newly copied code into optimized source code by compressing all JavaScript and CSS files, then scanning each HTM file, and finally concatenating all JavaScript and CSS files referenced in the HTM file. The build process reads the HTM files at run-time and enumerates all the JavaScript and CSS files in the HTM file that reside within a well-known comment syntax.
For example, all the JavaScript references within the following comment syntax
<!-- BEGIN:SCRIPT --> <script type="text/javascript" src="../wcm.js"></script> <script type="text/javascript" src="../base/wcm.dhtml.js"></script> <script type="text/javascript" src="../base/wcm.get.js"></script> <script type="text/javascript" src="../base/wcm.http.js"></script> <script type="text/javascript" src="../base/wcm.popup.js"></script> <script type="text/javascript" src="../base/wcm.compare.js"></script> <script type="text/javascript" src="../base/wcm.diff.js"></script> <script type="text/javascript" src="../sitestudio/wcm.idc.js"></script> <script type="text/javascript" src="../sitestudio/wcm.contentserver.popup.js"></script> <script type="text/javascript" src="../sitestudio/wcm.helpfiles.js"></script> <script type="text/javascript" src="../sitestudio/wcm.help.js"></script> <script type="text/javascript" src="../form/wcm.form.js"></script> <script type="text/javascript" src="wcm.sitestudio.form.js"></script> <script type="text/javascript" src="../custom/sitestudio/wcm.sitestudio.form.js"></script> <!-- END:SCRIPT -->
are compressed, concatenated, and referenced as
<!-- BEGIN:SCRIPT --> <script type="text/javascript" src="../wcm.sitestudio.form.composite.js"></script> <!-- END:SCRIPT -->
Similarly, the following CSS references within the following comment syntax:
<!-- BEGIN:CSS --> <link href="../base/wcm.base.css" rel="stylesheet" type="text/css" /> <link href="wcm.sitestudio.form.css" rel="stylesheet" type="text/css" /> <link href="../custom/sitestudio/wcm.sitestudio.form.css" rel="stylesheet" type="text/css" /> <!-- END:CSS -->
are compressed, concatenated, and referenced as
<!-- BEGIN:CSS --> <link href="wcm.sitestudio.form.composite.css" rel="stylesheet" type="text/css" /> <!-- END:CSS -->
To run the build process on Windows, double-click the shell-build shortcut in the following location:
\tools\optimize\shell-build
Use the following command line to run the build process on other Site Studio supported platforms, including Windows:
java.exe -cp ..\rhino\rhino1_7R2\js.jar org.mozilla.javascript.tools.shell.Main build.js
When running the build process from the command line, it is important to ensure that the execution working directory is that of the build script's directory. For instance, if executing the build from a shell, be sure to change directories to that of the build script (\tools\optimize) before executing the command line.
The process can also be run from the Manage Fragment Libraries page in Site Studio Administration. Click Compress Contributor JavaScript to start the process.
To run the visual debugger on Windows, double-click the shell-debug shortcut in the following location:
\tools\optimize\shell-debug
Use the following command line to run the visual debugger on other supported platforms, including Windows:
java.exe -cp ..\rhino\rhino1_7R2\js.jar org.mozilla.javascript.tools.debugger.Main build.js
When running the visual debugger from the command line, it is important to ensure that the debugger's execution working directory is that of the build script's directory. For example, if executing the debugger from a shell, be sure to change directories to that of the build script (\tools\optimize) before executing the command line.
Once the optimized Contributor source code is built, Site Studio can be configured to use the optimized source code by changing the SSContributorSourceDir value. This value can be set in the following configuration file:
CONTENT_SERVER_INSTALL_DIR\custom\SiteStudio\SiteStudio.cfg
Within sitestudio.cfg, set SSContributorSourceDir to the value wcm_min:
SSContributorSourceDir=wcm_min
Customizations made to the Contributor source code will be picked up by the build process automatically as long as the JavaScript and CSS file references reside within the special comment syntax. In addition, if newly added HTM files contain the special comment syntax around the JavaScript and CSS file references, then the build process will perform optimizations on those files.
The build script can also be modified to suit a user's customization needs. For instance, the output directory name or location can be changed. In addition, there are regular expression filters to determine which files get copied, compressed, or concatenated. These filters can be updated to suit any customizations as needed.
The use of memory in cached data can affect how responsive Site Studio is. One method of controlling this is done in the Site Studio program itself, where the memory requirements for the Site Studio structures were reduced by incorporating different changes.
Some of these changes include: disabling the Xerces deferred DOM loading and removing extraneous whitespace text nodes from the Project File DOM, among other changes.
The memory usage can also be controlled in the use of flags. This section covers the following topics:
The Xerces parser's deferred node expansion feature is known to be a very inefficient feature for small DOMs. However, it can be controlled via a flag.
The algorithms that compute the size of the items in the DOC_INFO cache, can be fine-tuned in two ways. The first way is to use a multiplier on the file size. The second is to enumerate the DOM. The following configuration flags are available:
SSComputeDocInfoCacheSize: A boolean value indicating if the size of the ResultSet should be computed or not. When the ResultSet size is not computed, the SSDocInfoCacheLowerBound value is used. The default is false.
SSDocInfoCacheLowerBound: This places a lower bound on the size of the ResultSet reported to the cache. The default is 2000.
SSDocInfoCacheMultiplier: A multiplier on the computed cache size to arrive at a final value reported to the cache. The reported value will be multiplied by 10 by the cache itself in its computations. The default is 0.1.
SSDocInfoCacheStringMultiplier: A multiplier for Strings lengths to produce the final string size in memory. The default is 2.
SSDocInfoCacheStringOverhead: The number of bytes to add per string. The default is 24.
SSDocInfoCacheColumnOverhead: The number of bytes to add per column in the ResultSet. The default is 40.
SSDocInfoCacheRowOverhead: The number of bytes to add per row in the ResultSet. The default is 24.
SSDocInfoCacheCellOverhead: The number of bytes to add per cell in the ResultSet. The default is 12.
Note:
These flags are used in Site Studio 10gR4, but not in Site Studio 11gR1.The algorithm that computes the amount of space that a SSXPathCacheEntry consumes in the ResourceCache, can be fine-tuned in two ways. The first way is to use a multiplier on the file size. The second is to enumerate the DOM. The following configuration flags are available:
SSDomCacheUseFileSize: Uses a cache size computation based on the size of the file. The default is true.
SSDomCacheUseDOM: Uses a cache size computation based on an enumeration of the XML DOM. The default value is false.
SSDomCacheLowerBound: Places a lower bound on the reported cache size. The default is 6000.
SSDomCacheMultiplier: Multiplies the computed cache size by the given value to arrive at a final value. The default is 0.1 because we currently recommend that the total number be multiplied by 10 to calculate the realistic size of the cache.
SSDomCacheNodeMultiplier: The number of bytes to count per DOM node. The default is 12.
SSDomCacheStringMultiplier: The number of bytes to multiply string lengths in the DOM by to produce the string size. The default is 2.
SSDomCacheStringOverhead: The number of bytes to add per string in the DOM. The default is 24.
SSDomCacheDefaultFileSizeFactor: The default value by which to multiply the file size to obtain a cache size. The default is 2.0.
SSDomCacheFileSizeFactors: A comma-separated list of file sizes and multipliers that control the computed cache size.
For example, the following string
1000,6.0,10000,2.7,50000,2.1,100000,1.9,300000,1.6
multiplies files sized [0...999] by 6.0,
multiplies files sized [1000...9999] by 2.7,
multiplies files sized [10000...49999] by 2.1,
multiplies files sized [50000...99999] by 1.9,
multiplies files sized [100000...299999] by 1.6,
(files outside the range above are multiplied by the value of SSDomCacheDefaultFileSizeFactor.)