This appendix describes how to modify the default configuration for portal components, and configure AquaLogic Interaction Logging Spy. It includes the following sections:
The default settings enable your portal to function fully. This section provides the following topics that describe how to customize the installation default portal settings:
If host names or IP addresses change after your initial deployment, you can use the Portal Settings utility to modify portal URLs.
To modify portal URLs:
Click Administration.
In the Select Utility drop-down list, click Portal Settings.
Modify portal URLs as needed.
Click Finish.
Modifying Portal Configuration Files
If your configuration requirements change after initial deployment, you can modify the configuration in files located in the PT_HOME/settings directory. PT_HOME is the AquaLogic User Interaction installation directory, for example, C:\bea\alui or /opt/bea/alui.
The following topics in this section describe the configuration files:
WebHome: The home directory for the portal JAR or DLL files.
ImageServerBaseURL: The base URL of the Image Service.
ImageServerSecureBaseURL: The base URL of the Image Service running HTTPS.
ImageServerConnectionURL: The base URL that is used when the portal connects to the Image Service to retrieve JSRegistry information. In many configurations, this URL is the same as the Image Service Base URL.
ImageServerConnectionURLTimeout: The timeout for ImageServerConnectiontionURL in seconds. A value of -1 means do not check during startup.
AdminSiteBaseURL: The base URL of the Administrative Portal.
TempHome: The temporary file directory to be used by the portal. This should not be Web accessible.
SystemProperties
ServerName: The name of the proxy server running the portal, that is, the mapped server.
MachineName: The server machine name, that is, the name of the portal behind the proxy server.
PerformanceComments: The setting for enabling or disabling the performance comments in the HTML source. 1= the comments are enabled, 0= the comments are disabled.
DoctypeSpecification: 1= none, 2= HTML 3.2, 3= HTML 4.0 Transitional, 4= HTML 4.0 Frameset, 5= HTML 4.0 Strict.
VirtualDirectoryPath: The virtual path to the portal, usually /portal/.
HTTPEntryPoint: Portal main Servlet mapping name. For Java (portalconfig.xml), this has to be the same mapping name as the HTTPServlet in web.xml. For .Net, the application mapping name has to be the same mapping name as the httpHandlers in web.config.
HTTPPort: The port number of the portal running HTTP.
HTTPSecurePort: The port number of the portal running HTTPS.
SSOVirtualDirectoryPath: Single sign-on (SSO) virtual directory path.
SSOServletName: SSO Servlet mapping name. For Java (portalconfig.xml), this has to be the same mapping name as the SSOLoginPage in web.xml. For .Net, this has to be the same name in SSOLogin.aspx file in the Default Web Site/portal/sso virtual directory.
URLMapping
The URL mapping determines the portal base URL according to the requested URL from the request object. The portal base URL is the base URL for every single link and redirection. For example, if your portal base URL were: http://portal.company.com/portal/server.pt, then the link to the default My Page would be: http://portal.company.com/portal/server.pt?space=MyPage.
You can add as many entries as you want to the mapping. Mapping URLs should start with http:// or https:// and end with the HTTP entry point name (unless it's the default value, "*").
ApplicationURL0: In SecurityModes 2 and 3, ApplicationURL should be set to the same value as SecureApplicationURL. In mode 0, ApplicationURL0 might be equal to "*". In this case, the Application Base URL will be the URL from the Request object.
SecureApplicationURL0: In SecurityMode 0, SecureApplicationURL is not used. In modes 2 and 3, SecureApplicationURL0 might be equal to "*". In this case, the Application Base URL will be the URL from the request object.
CachedSettings
Add entries for personal settings that should be cached on the http session of each user. Personal settings that are not included in this list will be retrieved from the portal every time they are requested. Settings that are on this list are obtained from the portal on login and are cached for the duration of the user's http session.
Note: AccessStyle, Locale, and TimeZone should always be cached by the server.
Users can customize these settings by clicking My Account in the portal interface. For instructions and a detailed description of any page in the portal, click Help.
The following settings are cached by default:
Greeting: Stores the personalized greeting that displays on the portal banner when the user logs into the portal.
AccessStyle: Stores the user display option.
Locale: Stores the preferred language of the portal interface. Portlet names and content display in the selected language only if the language is supported by the portlets. It also stores the format for portal entries (including search requests). For example, if the user chose British English, the portal displays and expects dates in the DD/MM/YYYY format (whereas in American English, the portal displays and expects dates in the MM/DD/YYYY format).
TimeZone: Stores the time zone of the user.
PortletTimeout: Stores the maximum time to wait for a portlet to load.
CollapsedGadgets: Stores which portlets were minimized by the user.
COMCollapsedGadgets: Stores which portlets in the community page were minimized by the user.
MyPageRefreshRate: Stores the refresh rate of user My Pages.
Authentication
AllowGuestAccess: Allow the guest user to access the portal. If guest access is not allowed, the portal will always prompt for login information.
GuestPassword: This is the password for the guest user. Changing this password requires that it be changed here and in the portal database itself.
GuestRedirectToLogin: If the guest user does not specify a space in the URL query string, this setting determines the initial page the user sees.
Users can navigate to different portal pages by including "space=xxxx" strings in the URL query string. For example, if the user were to type: http://MYSERVER/portal/server.pt?space=MyPage, the user will be directed to the My Page (the access privileges of that page will be in effect).
However, if the user did not include a "space=xxxx" string in the query string (that is, the user only typed: http://MYSERVER/portal/server.pt), the portal directs them to a default page, depending on the GuestRedirectToLogin setting and the experience definition settings, as shown below:
GuestRedirectToLogin Setting
Description
0
The portal will redirect the guest user to the home page defined in the current experience definition (usually a My Page or community page).
1
The portal will redirect the guest user to the login page as defined in the current experience definition.
RedirectOnLogout: After logging out the user is redirected to a default page as shown below:
RedirectOnLogout Setting
Description
0
The portal will redirect the guest user to the home page defined in the current experience definition (usually a My Page or community page).
1
The portal will redirect the guest user to the login page as defined in the current experience definition.
Security
SecurityMode: This setting determines which pages will use SSL encryption. You must install a digital certificate and enable SSL on your Web server before changing the default value of 0.
The portal does not check the security of incoming requests.
In mode 0, ApplicationURL0 and SecureApplicationURL0 may be equal to "*". In this case, the Application Base URL will be the base URL from the Request object.
1
Selected pages that involve sensitive information such as passwords use SSL, while other pages are sent unencrypted for better performance.
Only pages of Activity Spaces listed in SecureActivitySpaces.xml (which is located in the same folder as portalconfig.xml) are sent through HTTPS.
The portal verifies that links and redirections to Secure Activity Spaces uses HTTPS. If a secure Activity Space were requested through a non-secure URL, the portal would redirect the same request to HTTPS.
If XPRequest.GetRequestURL() is equal to URLFromRequest0, ApplicationURL0 and SecureApplicationURL0 might both be the Application Base URL, depending on the security of the Activity Space.
You must install a digital certificate and enable SSL on your Web server.
2
Every page uses SSL.The portal verifies that every single incoming request uses HTTPS. If it does not, the portal will redirect this request to HTTPS. This setting is best for very secure applications where performance is not a major concern.
If the URL from the Request object is equal to URLFromRequest0, SecureApplicationURL0 will be the Application Base URL.
URLFromRequest0 has to be equal to "*". This is the default entry. It will be used if no mapping entry matched the URL from the Request object.
You must install a digital certificate and enable SSL on your Web server.
3
Select this mode if you are using an SSL Accelerator. Because the portal is behind an SSL Accelerator, the security of the incoming requests is not verified. The portal trusts every request from the SSL Accelerator. All the links and redirections are in HTTPS.
If URL from the Request object is equal to URLFromRequest0, SecureApplicationURL0 will be the Application Base URL.
URLFromRequest0 has to be equal to "*". This is the default entry. It will be used if no mapping entry matched the URL from the Request object.
You must install a digital certificate and enable SSL on your Web server.
International
Locale: The default locale for new users. If you set locale to UseBrowser, the portal derives the locale from the browser language settings. The user locale setting, stored when creating a user from a user profile (or configured in My Account | Edit Locale in the portal) overrides the locale setting in the portalconfig.xml file.
TimeZone: The default time zone for the user. The user time zone settings (configured in My Account | Edit Locale in the portal) overrides this setting. The portal uses the settings in this file only if the user has not configured his or her default time zone.
MandatoryObjectLanguage: This setting allows the administrator to set the language for all new objects. If it is blank, the user creating the object can choose the language for the object. If it is not blank, the value will be used as the language for all new and edited objects. The value should be a locale string (that is, it should match the name of a folder under the msgs directory).
Documents
NewDocumentTime: The number of days that a document or folder displays "new" after its name.
DocumentLastUpdated: The number of days that a document displays "updated" after its name.
OpenNewWindow: The default setting for the open in new window preference. 0= same window, 1= new window. Users can override this setting by changing their personal preferences.
Content Crawlers
MaxWebCrawlRadius value: The setting for the maximum number of links away from the target page that you want to crawl. For example, if you select 1, the content crawler attempts to import every page directly linked to the target page; if you select 2, the content crawler attempts to import every page directly linked to the target page, and every page directly linked to those linked pages. This setting corresponds to the Crawl Radius drop-down list in the Web Content Crawler Editor. The default maximum is 4, which means the drop-down list allows a crawl radius of 1 to 4.
Style
StyleSheetName: The name for the portal's default stylesheet.
Communities
DefaultCommunityID: Configure this setting only if your navigation scheme is Tabbed Section Left Vertical Navigation or if you use a custom navigation scheme that uses the IPluggableNavModelRO.GetDefaultCommunity() method. In these cases, the setting specifies the ID of the default community to display when a user clicks the Community tab.
CommKnowledgeDirLinksPerPage: The number of links to display on one screen in the community Knowledge Directory.
Administration
IsAdminSite: Determines whether the computer is an administrative portal or a browsing-only portal.
Table A-2 Portal Modes
Portal Mode
Description
0
Sets the computer into a browsing-only portal.
1
Sets the computer into a browsing and administrative portal.
AdminObjectsPerPage: Determines the number of administrative objects of a single type (for example, content crawlers or content sources) allowed to display on one screen. This controls the number of items displayed on the administrative interface. The default is 10.
Authentication
AllowDefaultLoginPageAuthSource: Controls the use of the default authentication source for portals (that do not use single sign-on) on the login page and Login Portlet. It also lets you configure the authentication source drop-down list.
Table A-3 Authentication Source Modes
Authentication Source Mode
Purpose
Appearance
Required Actions
0
The portal does not use the default authentication source.
The drop-down list has no special ordering.
Default mode.
1
The portal uses the default authentication source.
The drop-down list is hidden, but it displays a link that brings up the authentication source drop-down list. This lets users select a non-standard authentication source.
You must turn off the caching on the Login Portlet or disable the Login Portlet.
You must set the DefaultAuthSourcePrefix tag to the prefix of the authentication source that is the default for all users.
2
The portal uses the default authentication source.
The drop-down list is not hidden, and the default authentication source is pre-selected.
You must turn off the caching on the Login Portlet or disable the Login Portlet.
You must set the DefaultAuthSourcePrefix tag to have the prefix of the authentication source that is the default for all users.
3
The portal uses the default authentication source.
The drop-down list is permanently turned off.
DefaultAuthSourcePrefix: Sets the default authentication source prefix that will be prepended to the login name when users log into your system, unless they select another authentication source from the drop-down list on the login page. In the case of SSO, this is the authentication source category for all of your SSO users.
You can use AuthSourcePrefix tags to order the items in the authentication source drop-down list. Entries in the list should look like the following:
where [i] is replaced with the items' order in the drop-down list (starting with 1).
To include the AquaLogic Interaction Authentication Source in the list, simply make an entry with "AquaLogic Interaction Authentication Source" as the value. The AquaLogic Interaction Authentication Source is for users who are created in the portal, manually, through invitations, or through the Create an Account page. For example, to include the AquaLogic Interaction Authentication Source as the third item in the drop-down list, use the following tag:
Authentication source prefixes in the ordered list are displayed first in the drop-down list and are followed by any authentication sources not included in the ordered list.
AllowAutoConnect: Setting for saving passwords in cookies.
Table A-4 Auto Connect Modes
Auto Connect Mode
Description
0
Turns off the option of saving passwords in a cookie.
1
Users will see a "Remember my password" check box on the login page of your portal. Passwords are saved as cookies for users that select this check box, which lets users who navigate to your portal be logged in automatically.
CaptureBasicAuthenticationForPortlets: Determines whether or not to capture basic authentication information (login and password) and store it in the session (to send to portlets). The basic authentication information cannot be captured when users select "Remember my password" to login via a cookie. 1= , 0= .
Table A-5 Session Store Modes
Session Store Mode
Description
0
The authentication information will not be stored in the session.
1
The authentication information will be stored in the session.
RememberPassword: This setting allows you to set how long the portal remembers your login password. The value should be formatted in minutes. The default is one week.
SSOVendor. Sets the single sign-on configuration. For information on SSO, see Deploying Single Sign-On.
Invitations
IsInvitationURLSecure: Sets the security of the invitation URL.
Use a secure URL only if you disable http.
Table A-6 Invitation Security Modes
Invitation Security Mode
Description
0
Unsecure. The URL uses http://. You can use an unsecure invitation URL with any security mode, so long as you do not disable http or have http URLs redirect to https.
1
Secure. The URL uses https://. If the SecurityMode setting in your portalconfig.xml file does not allow http, you must select this mode.
serverconfig.xml
You can edit serverconfig.xml to modify the following connection and path information for portal components.
Table A-7 Elements of serverconfig.xml
Element
Description
Logging
<ServerName> specifies the name of the portal host computer on which logs are collected.
<LocalMachineOnly>, when set to true, specifies log collection for only the local host, not the network of portal hosts.
Database
<Common> contains elements to configure connection information for the portal database, such as database type, database name, host name, database user and password, as well as login timeout and pool connection settings.
SysManagement
<JMXView> indicates whether or not the JMX-based management is enabled.
<JMXRemoteService> configures the port on which the RMI registry listens.
HTTP
<DefaultProxy> configures http proxy settings for the portal.
<HttpContentCache> configures the cache size.
Content Crawlers
Contains default settings for content crawler transactions.
Gateway
Contains default settings for gateway transactions.
Search
Contains default settings for search transactions.
Configuring the Automation Service
The default settings enable your Automation Service to function fully. If your configuration requirements change after initial deployment, you can modify the PT_HOME/settings/serverconfig.xml file to specify a new configuration for the Automation Service. The AutomationServers element contains the following settings.
Table A-8 Elements of Automationserver.xml
Element
Description
Nodes
Configures the port number for the Automation Service.
MaxConcurrentJobs
Configures the number of jobs that can run at the same time.
VirtualMachineArgs
Configures tuning values for the JVMs of individual jobs run by the Automation Service.
Fine-Tuning the Search Service Configuration
The installer sets most Search Service configuration parameters to useful defaults. In addition to the default configuration file, the PT_HOME/ptsearchserver/6.0/config directory includes template configuration files for Search Service deployments. The templates include settings appropriate for a number of operating systems and RAM configurations. RAM determines the recommended maximum number of documents in the search collection, and this collection size determines many of the settings in the template configuration files. Examine the contents of these files, choose the one appropriate for your deployment, and rename the template ignite.ini (the active configuration file).
Note:
If the Search Service component resides on the same host computer as other portal components, consider using a template tuned for a smaller amount of memory to prevent system paging that adversely affects Search Service performance.
In some cases you might be able to further improve performance by modifying some of the values in the ignite.ini file. This section includes the following topics that describe the parameters in ignite.ini:
The following parameters appear in ignite.ini by default:
RFINDEX: Directory used to store Search Service index files. By default, the installer puts these files in the PT_HOME/ptsearchserver/6.0/index subdirectory. The directory should have sufficient space for the collection you are indexing.
You should not change this parameter unless you move your index files or are instructed to do so by customer support (ALUIsupport@bea.com).
RFPORT: Port that the Search Service uses for communication with other processes (mainly the portal). The installer prompts for this port number during installation. This value displays in the Search Service Manager, on the Host Settings page. If you change this value in ignite.ini, you must also change the value in the Search Service Manager or the portal will malfunction.
RF_MAPPING_TOKEN_CACHE_SIZE: Specifies the size of the cache of mapping tokens. These tokens represent thesaurus and Best Bets entries read from the mappings collection. The default value is 5000. This parameter is chosen in the configuration file templates to reflect the expected number of tokens associates with the maximum supported collection size. The value of this parameter does not have a large effect on Search Service performance. Each cache element is 120 bytes in size, so the default mapping cache will occupy 600 kilobytes of memory.
RF_LOG_VERBOSITY: Numeric parameter that determines how much information is logged in the Search Service logs. Values range from 0 to 5. The default is 3 (high verbosity). You generally do not need to change this parameter. We recommend you not set this below 3. If RF_LOG_VERBOSITY is set below 3, the reports generated by the Search Log Analysis external operation (and viewable on the Search Results Manager) will not contain all of the information needed to support log analysis.
RF_DOCUMENT_TOKEN_CACHE_SIZE: Numeric parameter that specifies the size of the cache of document tokens. These tokens are words from the actual indexed content in the Search Service. The default value is 250000. This parameter has a significant effect on Search Service indexing and query performance, with larger values providing better performance. This parameter is chosen in the configuration file templates to reflect the expected number of tokens associates with the maximum supported collection size. Each cache element is 120 bytes in size, so the default document token cache occupies 29 megabytes of memory.
RF_SPELL_TOKEN_CACHE_SIZE: Numeric parameter that specifies the size of the cache of spelling tokens. These tokens are word fragments from the spelling data derived from the indexed content. The default value is 250000. This value does not need to be larger than the number of tokens in the spell collection, and it does not need to exceed the value in the configuration file templates provided in the config directory. This parameter has a significant effect on indexing performance, spell checking, and wild card queries. If these operations seem particularly slow, you can increase the value specified by this parameter. In practice, values larger than 1000000 provide diminishing return while consuming significant amounts of memory. Each cache element is 120 bytes in size, so the default spell cache occupies 29 megabytes of memory.
RF_INDEX_CACHE_BYTES: Numeric parameter specifying the size of the index cache in bytes. The default value is 78643200 (75 megabytes). The value of this parameter has a significant effect on Search Service query performance. The index and docset (see RF_DOCSET_CACHE_BYTES) caches should be made as large as possible while leaving sufficient memory available for the Search Service's other needs.
RF_DOCSET_CACHE_BYTES: Numeric parameter specifying the size of the document cache in bytes. The default value is 2614400 (25 megabytes). The value of this parameter has a significant effect on Search Service query performance. The index and docset (see RF_INDEX_CACHE_BYTES) caches should be made as large as possible while leaving sufficient memory available for the Search Service's other needs.
Optional Search Service Parameters
Optionally, if advised by customer support, you can add the following values to the ignite.ini file:
RFLOG: Directory where the Search Service writes its logs. The default is the <SearchServerInstall>/logs subdirectory. Edit this value only if you change this directory; the new directory must exist and must be writable by the Search Service.
RF_HIGH_PRIORITY: If this parameter is set to any value, Search Service attempts to increase its process priority over that of other processes. This is not normally necessary, but might be useful on a computer where other processes compete for resources with the Search Service.
RF_MAX_WILDCARD_EXPANSIONS: When a user enters a query that uses a wildcard (for example, "plum*"), this parameter determines the maximum number of terms into which the wildcard is expanded (for example, plum, plums, plumber). The default is 100 terms. This limit keeps overly general queries ("*ing") from expanding into a huge number of terms and consuming too much time and memory. In large installations, you might need to increase this value.
RF_MAX_QUERY_MSECS: Maximum time, in milliseconds, for user queries. The default is 10000 (ten seconds). After processing the query for this much time, the Search Service returns results it has found so far. You might want to lower the value of this parameter if end users complain that ten seconds is too long to wait for query results.
RF_MAX_TOTAL_RESULTS: Maximum number of results returned by a query. The default is 10000. You do not generally need to change this parameter because the portal displays fewer results than the Search Service maximum.
RF_MAX_NUM_STATIC_ARCHIVES: Maximum number of static archives per collection created in the index directory. The default is 50; this means that there will be up to 50 archive.NNN.docset files (where NNN is a number), archive.NNN.index files, and so on. There can also be up to 50 spell.NNN.docset files, spell.NNN.index files, and so forth. You do not generally need to change this parameter; the only reason might be an operating system (such as Solaris 2.6) that does not allow the Search Service to use enough file descriptors to open all the files at once. Lowering this number causes archive merges to use more memory and disk space.
RF_QUERY_THREADS: Number of threads to dedicate to query processing. The default is 8. You might need to increase this parameter if your Search Service is under heavy load. The value should represent the expected number of simultaneous queries. If this value is too low, incoming queries will wait on a queue for the next free query thread and users will experience longer query times (possibly several seconds).
RF_QUERY_QUEUE_SIZE: When all Search Service query threads (see RF_QUERY_THREADS) are busy, incoming query requests are placed on a queue to wait for the next available query thread. This parameter determines the length of that queue. The default value is 20 and usually does not need to be changed. Should the query queue ever become full, additional query requests are rejected and a message is written to the Search Service logs. If this happens, you can increase RF_QUERY_QUEUE_SIZE.
RF_INDEX_THREADS: Number of threads to dedicate to indexing requests. The default is 2. You might need to increase this parameter if the indexing performance of your Search Service is too low. However, devoting additional system resources to indexing will reduce query performance. Ideally, the value of RF_INDEX_THREADS should not exceed the number of CPUs on the system.
RF_INDEX_QUEUE_SIZE: When all Search Service index threads (see RF_INDEX_THREADS) are busy, incoming index requests are placed on a queue to wait for the next available index thread. This parameter determines the length of that queue. The default value is 20. To estimate a good value, add the number of threads in all content crawlers that might be running simultaneously (you can request up to four threads when setting up a content crawler). To be conservative, make your estimates high. If this parameter is too low, content crawlers can fill the index queue and the Search Service rejects additional index requests until the queue has room for more requests.
Note:
It is better to schedule nonoverlapping crawls than to set a high value for RF_INDEX_QUEUE_SIZE; consider changing the crawl schedule before modifying this parameter.
RF_HANDSHAKE_THREADS: Number of threads to dedicate to servicing incoming socket connections. The default is 5. This value should never need to be changed.
RF_HANDSHAKE_QUEUE_SIZE: Socket connections from Search Service clients are placed on this queue to await acknowledgement by one of the handshake threads (see RF_HANDSHAKE_THREADS). This parameter determines the length of that queue. The default value is 20. Once successfully acknowledged, the connections are assigned to either the query or index queue. Under exceptionally high loads, this queue might fill up and the Search Service will reject new connections until the queue has room for more requests. Should this happen, you can increase the value of this parameter.
RF_TOKEN_LEXICON_REBUILD_LIMIT: Maximum lexicon size, measured in number of tokens, to rebuild automatically. If the Search Service detects that the lexicon was closed improperly, the lexicon is rebuilt as part of the startup process. This can be time consuming. The default value is 400000, ensuring that the rebuild requires no more than a few minutes. Larger lexicons needing repair must be rebuilt with the standalone examinearchive utility. You might change the value or set it to zero to allow automatic rebuild of arbitrarily large lexicons.
In Windows Systems: Setting this value too large can result in error dialogs being posted by the Windows Service Control Manager when the Search Service is run as a Windows service and a lexicon rebuild is performed. These error dialogs indicate that the service is failing to start in a timely manner. They can be disregarded.
RF_USE_DATA_FILE_CACHE: Numeric parameter indicating whether the Search Service should use caches when accessing index and document data. A value of zero disables the caches and causes the Search Service to use memory-mapping. A nonzero value activates the caches. The default value is 1. We strongly recommend you do not change this value.
This parameter serves as the master on/off switch for RF_INDEX_CACHE_BYTES, RF_DOCSET_CACHE_BYTES, RF_INDEX_CACHE_MAX_PAGES_PER_BLOCK, and RF_DOCSET_CACHE_MAX_PAGES_PER_BLOCK. When RF_USE_DATA_FILE_CACHE is zero, these other parameters have no effect.
Disabling the caches for small search collections (less than 1 gigabyte of data) might provide a slight improvement in performance depending upon the amount of available physical memory on the Search Service host. In memory-mapped mode, the Search Service fails if the index and document data, plus the Search Service's internal data structures should exceed 2 or 3 gigabytes (depending upon the operating system configuration).
RF_REQUIRED_DISK_SPACE: Amount of disk space (in KB) required to start a dynamic index merge. When merging dynamically indexed data into the search collection, the Search Service verifies that this amount of free space is available on the volume containing the search collection. If the space is not available, the merge process aborts, the Search Service enters read-only mode, and further dynamic indexing requests are rejected. The default value for this parameter is 40000 and should not need to be changed.
When you modify cache settings, keep the following important values and relationships in mind:
A RF_DOCSET_CACHE_BYTES:RF_INDEX_CACHE_BYTES ratio of 1:3 has been empirically determined to provide near-optimal cache performance for typical search collections.
Reasonable values for RF_MAPPING_TOKEN_CACHE_SIZE are 500 to 10000.
For performance reasons, document offsets and index offsets data is accessed via memory-mapping, regardless of the setting of RF_USE_DATA_FILE_CACHE in the ignite.ini file. This means that the memory footprint of a running Search Service depends on the size of the search collection, and this consideration has been calculated in the settings for the configuration file templates in the config directory. The amount of memory needed for these mappings can be calculated approximately as (Size of *.docsetOffsets files in bytes) + 0.006 * (Size of *.index and *.key.index files in bytes)
Leave sufficient address space (and, ideally, physical RAM) available for the number of query and index threads. Allow 10 MB per query thread (see RF_QUERY_THREADS) and 50 MB per index thread (see RF_INDEX_THREADS).
Using the Config Tool to Modify Database and Portal Logging Settings
The Config Tool provides a graphical user interface to simplify making changes to the database settings, and to test the database connection. In addition, you can use this tool to enable logging messages from the portal server to be viewed remotely.
The changes you make using the Config Tool affect settings in the serverconfig.xml file.
To use the Config Tool:
From a command prompt, enter ptconfig.exe (Windows) or ptconfig.sh (Unix).
In the Config Tool window:
To change the database login and password settings, click the Database Settings tab, and enter the desired settings, along with the database host, port number, and database type.
To test the database connection, on the Database Settings tab, click Test DB Connection. A status message is displayed.
To enable remote viewing of portal logging messages, click the Logging Settings tab. Enter the server name, and under Local Machine Only, click False.
Note:
This only enables remote logging for the portal server, not the automation or the API servers. To enable remote logging for those servers, modify the serverconfig.xml file:
To enable remote logging for the automation server, in the automation server logging section, set logging:local-only to false.
To enable remote logging for the API server, in the wsserver logging section, set logging:local-only to false.
Click OK.
Restart the portal for the configuration changes to take effect.
Configuring AquaLogic Interaction Logging Spy
Portal is installed with AquaLogic Interaction Logging Utilities, and by default is set to send log messages to those utilities. You can configure the portal to disable logging or to enable remote logging (to have the portal send log messages to a separate machine on a network). For information on how to configure portal logging, see the Installation and Upgrade Guide for AquaLogic Interaction Logging Utilities.
AquaLogic Interaction Logging Spy (formerly PTSpy) is the primary log message receiver in the AquaLogic Interaction Logging Utilities. AquaLogic Interaction Logging Spy provides a graphical user interface for displaying log messages as they stream in from the portal and other log message senders (such as AquaLogic Interaction Collaboration or AquaLogic Interaction Publisher).
Configuring AquaLogic Interaction Logging Spy to Display Portal Messages
To configure AquaLogic Interaction Logging Spy to display portal messages:
Launch AquaLogic Interaction Logging Spy by navigating to Start | All Programs | BEA | ALI Logging Utilities | Logging Spy. For more information on using AquaLogic Interaction Logging Spy, see the Online Help provided with AquaLogic Interaction Logging Spy.
Open the Filter Settings window by selecting View | Set Filters.
To add a logging sender, right-click anywhere in the Filter Settings window. The context menu appears.
Type a server name or select it from the list of names and click OK.
Server names exist in the <logging:server-name> nodes of the Logging sections in the portalconfig.xml file.
When you add a server as a message sender, it appears in a tree structure in the Filter Settings window. Click the plus sign to expand the server and see a list of its message-sending components.
In the Filter Settings window, expand each component under a server to see the selected logging levels for that component.
The checkbox next to each component has three states:
Gray with a check mark - some, but not all, logging levels are selected
Clear with a check mark - all of the logging levels are selected
Clear - none of the logging levels are selected
You can toggle through these states by clicking the checkbox next to the component.
You can perform the following additional actions in the Filter Settings window:
To remove a message-sending server and its components, right-click on the server name, and select Remove Message Sender.
To enable a selected logging level for all components of a server, right-click on the server name, and select Enable <LoggingLevel>, for example, Enable Performance.
To enable or disable logging levels for a single component, expand the component, and select or clear the checkbox next to the logging level.
To clear all logging levels for all components of a server, right-click on the server name, and select Clear All Filters. Then click OK when asked to confirm. This prevents those components from sending logging messages to this instance of Logging Spy.
To reset logging levels for all components of a server to the original four levels, right-click on the server name, and select Reset Filters. Then click OK when asked to confirm.
Help.
