ShowTable of Contents
Note: For 'general' performance recommendations, see this link Database TuningGeneral Database Tuning Recommendations- For non-z/OS platforms, use a dedicated server (ie. don't place portal/wcm on the same machine as the database server)
- Monitor CPU activity of database server and add additional hardware as required. ie, For z/OS platforms, ensure that the database has enough CPU power and for non z/OS platforms, ensure that there are enough database nodes (of sufficient power)
- Perform database tuning as indicated in database products documentation
- Split portal domains (eg. WMM, WPS, JCR etc) into their own databases rather than one database with multiple schemas
- Monitor database usage over time and add/remove Database indexes to improve performance specific to the customer's usage pattern
- If you are using a version of Web Content Management prior to 6.0.1.2, then consider upgrading to version 6.0.1.2 or later to take advantage of the new database indexes present in 6.0.1.2 that improve rendering and authoring performance
- If you are using WCM version 6.0.1.3 only, then run the following tasks to ensure that the JCR schema and indexes are correct:
- \config\WPSconfig \WPSconfig.bat action-update-wcm-indexes
- \config\WPSconfig \WPSconfig.bat action-update-jcr-6013
- (Ensure that jcr.database.userid and jcr.database.password are specified in \jcr\lib\com\ibm\icm\icm.properties first)
- Use a ratio of at least 2.5 to 1 Database Connections (for z/OS the terminology is threads) to WAS WebContainer threads (for the Portal Server running Web Content Management)
- The Database connections setting is different for each database, for DB2 LUW it's called 'MAXAPPLS' and is generally specified per database.
- If your database has a dynamic max connections setting that allows as many connections as possible (DB2 LUW has this ability when MAXAPPLS is set to 'automatic') then this setting can be used instead
- For DB2 LUW, you can get the MAXAPPLS setting by connecting to the database and issuing 'get db cfg'. You can change the setting by issuing: 'update db cfg using MAXAPPLS value /AUTOMATIC
- The WAS WebContainer Thread setting for Portal is located here: 'Application Servers > WebSphere_Portal > Thread Pools > WebContainer > Maximum Size
- If using WCM and PZN together, then the 3.5 database connections per thread should be used
- As the lab continuously works to improve performance across the board, we recommend that all customers move to WCM 6.0.1.4 or later so that they can take advantage of WCM's cumulative iFix strategy which produces a regression tested cumulative iFix every 2 weeks approx
DB2 LUW Performance Recommendations- See DB2 Tuning section from Official Portal Tuning Guide and periodically run the recommended 'reorg' and 'runstats' commands
- If you have a small website, then consider changing the DB2 query level to 2 (for the JCR Database):
- HOW TO ENABLE:
- Enter the following commands from the DB2 Command prompt:
- DB2 CONNECT TO [JCR_DB] [USER] USING [PASSWORD]
- DB2 UPDATE DB CFG FOR USING DFT_QUERYOPT 2
- DB2 DISCONNECT
- Restart the DB2 service
- Restart the Portal Server
- HOW TO DISABLE:
- Enter the following commands from the DB2 Command prompt:
- DB2 CONNECT TO [JCR_DB] [USER] USING [PASSWORD]
- DB2 UPDATE DB CFG FOR USING DFT_QUERYOPT 5
- DB2 DISCONNECT
- Restart the DB2 service
- Restart the Portal Server
- Ensure that the JCR database is not running with 'UCA400_NO' collation enabled
- While this has been corrected in newer portal installs, if your PortalServer\config\templates\db\db2\createdb2.bat file (PortalServer\config\templates\db\db2\createdb.sh for Unix), contains 'COLLATE USING UCA400_NO' in the 'create db' then its likely that your database has 'UCA400_NO' collation enabled. If you have heavy CPU on your database server, then this is the likely cause.
- To switch back to binary collation, perform the following steps:
- HOW TO SWITCH TO BINARY COLLATION:
- Install a new version of Portal on another machine
- Edit the PortalServer\config\templates\db\db2\createdb2.bat file (PortalServer\config\templates\db\db2\createdb.sh for Unix), as follows:
- Copy the 'CREATE DB..' line and place the copy immediately after the first instance
- Comment out the first 'CREATE DB' line by adding 'REM' ('#' for Unix) to the front of the line
- Eg. REM db2 -v "CREATE DB %1 USING CODESET UTF-8 TERRITORY us COLLATE USING UCA400_NO PAGESIZE 8192"
- Remove the string 'COLLATE USING UCA400_NO' from the second 'CREATE DB' line
- Follow the Portal InfoCenter instructions on switching to DB2 Storage
- Syndicate all data to the new server
- Either switch to use the new server, or perform a DB2 backup of the data and restore it to the original server
- HOW TO SWITCH BACK TO 'UCA400_NO' COLLATION:
- Install a new version of Portal on another machine
- Follow the Portal InfoCenter instructions on switching to DB2 Storage
- Syndicate all data to the new server
- Either switch to use the new server, or perform a DB2 backup of the data and restore it to the original server
- If you find that your menus and navigators are producing results which sort in case sensitive manner, itself of case insensitive, then enable the JCR collation support discussed here: http://publib.boulder.ibm.com/infocenter/wpexpdoc/v6r1m0/index.jsp?topic=/com.ibm.wp.exp.doc/config/linux_db2_cfg_collation.html
DB2/z Performance Recommendations- When the DB2 z/OS server is on a different server to the Portal/WCM installation, the use of the Universal Driver type 4 database driver is recommended
- For data sharing groups, we additionally recommend enabling Sysplex exploitation
- See the following technote for a TCP/IP problem on z/OS that can effect the communication to the DB2/z database from a remote machine (http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10621)
- While you will need to consult your DB2 z/OS DBA to tune your database to your needs, considering impacts on other applications using the database server, here are some initial confi g urat ion settings to start with:
- DSMAX: This value specifies the maximum number of data-sets (which includes both tablespaces and indexes) to keep open at a particular time. This value should be set to set high enough so the system doesn't try to pseudo-close data-sets too early.
- CHKFREQ=2
- This value determines how often to take a system check point (in minutes, between 1 and 60) and effects the DB2 restart ti me after a failure. Based on the rate of change and the customers SLAs, you might need to set CHKFREQ to 1, assuming your hardware can handle it of course.
- While CHKREQ can also be specified in terms of the number of log files written (between 200 and 160,000), we used minutes to have greater control over the system (your DBA will likely have a preference)
- PCLOSEN=15
- This value specifies the length to time to wait, after the last update (in terms of the number of checkpoints) before converting a page-set (aka index) from read-write to read (eg. pseudo-closed).
- The length of time to wait in minutes, is calculated by CHKFREQ x PCLOSEN.
- Converting page-sets between read-write and read (and vice versa) is slow, so you should initially aim for page-sets to be pseudo-closed after approximately 30 mins and then let your DBA further tune the system from there (if required)
- PCLOSET=35
- This value specifies the length to time to wait, after the last update (in terms of minutes) before converting a page-set (aka index) from read-write to read.
- This value is more important when the CHKREQ is set as the number of log files written, where it usually becomes the first threshold reached.
- When CHKFREQ is set as minutes, PCLOSET is used as a backup, whereby it's typically set slightly higher than CHKFREQ X PCLOSEN.
- When CHKFREQ is set as the number of log files, this value should initially be set to approximately 30 (for 30 mins) and then your DBA can further tune the system from there (if required)
- Recommended INDEX options (in index creation statement)
- NOPADDED
- Default is PADDED, which means that database can't solve queries by index alone
- Requires DB2 z/OS V8 or later and only applies to indexes that contain VARCHAR columns
- CLUSTER
- Can only be specified on one index per table, if multiple indexes per table, should be specified on the one most likely to be traversed
- Optimizes the data ordering (to make the index) which speeds up traversal
- Ensure that each table is defined with its own tablespace, to make management easier (as most administration commands run on a per tablespace level, not table level)
- Ensure that each tablespace has a specific bufferpool specified, rather than using the default BP0 bufferpool
- Your DBA should be able to tell you which bufferpools to use
- Additionally we would recommend to separate data, index and LOBs into different bufferpools
- See the following JCR DB2/z Technotes for additional information:
Oracle Performance Recommendations- Its recommended that customers upgrade to Oracle v10.2.0.4 when its available and in the meantime use Oracle v10.2.0.3 (+ Oracle patch 6116131 which fixes bug 4724074)
- Disabling some optimizations (via the below commands) have shown very large performance improvements at a number of customers, and thus are strongly recommended:
- alter system set "_b_tree_bitmap_plans" = FALSE;
- alter system set "_optimizer_cost_based_transformation" = OFF;
- Running database statistics periodically is critical to ensuring database performance over the long term, the Oracle run statistics command is:
- execute dbms_stats.gather_database_stats(dbms_stats.auto_sample_siz e,method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO', cascade=>TRUE);
- While you will need to consult the Oracle Documentation and/or an Oracle DBA to tune your database, these are the settings that IBM has been using internally:
- Oracle DB Settings:
- db_files=1024
- db_cache_size=500M
- sessions=665
- sga_target=1610612736
- db_writer_processes=20
- sort_area_size=65536
- CURSOR_SPACE_FOR_TIME=true
- SESSION_CACHED_CURSORS=500
- shared_pool_size=512M
- processes=600
- log_checkpoints_to_alert=true
- log_checkpoint_interval=0
- log_checkpoint_timeout=0
- fast_start_mttr_target=3600
- open_cursors=1600
- log_buffer=400m
- db_cache_size=536m
- pga=300m
- pga_aggregate_target=314572800
- pre_page_sga=true
- sga_max_size=1536m
- Oracle DB Tablespace settings:
- SYSAUX: 600MB
- SYSTEM: 600MB
- TEMP: 300MB
- UNDOTBS1: 400MB
- USERS: 800MB
- Redo Log Groups: 400MB
- Use a dedicated server for the LDAP server.
- Monitor CPU activity of the LDAP server, and add additional hardware as required.
- Perform tuning as indicated in LDAP products documentation.
- Avoid too many nested groups.
- Set the subscriber.only property to 'true' in WCMConfigServices.properties for all Workplace Web Content Manag ement in stances that will not syndicate their repositories to other servers. This stops the monitoring task from running on the Workplace Web Content Management instance that tracks object changes for later syndication to another server.
- Whenever the subscriber.only setting is changed, also reset the EventLog (WPS_ROOT\config\WPSConfig wcm-reset-event-log) before restarting the server
- Ensure there are no more than 5 subscribers per syndicator
- Increase the syndication interval from 30 seconds if frequent syndication is not required in your environment
- Do not enable a syndicator on a delivery server
- NOTE: Be aware of known DST issues with WCM and JCR, see this technote: http://www-01.ibm.com/support/docview.wss?rs=1041&uid=swg21377989
Optimising Menu Components- Avoid too many search criteria (in 'Menu Element Query' section)
- Avoid utilising the options in the 'Further options' section for each criteria unless really necessary, as this stops the menu from being internally cached
- For Category and/or Site Area restricted menus, only select both 'Ancestors' and 'Descendents' if really necessary and limit the number of categories and site areas specified
- Disable sorting by 'Description' unless really required (set the value to one of the other sort fields to disable)
- For unsecure sites (where content is accessed anonymously or always accessed by the same user, eg. Administrator), set 'Maximum pages to include' and 'Pages to read ahead' to 1
- If using multiple libraries, ensure that at least 1 site area is selected in each menu otherwise the menu will search against all libraries
- Menus should not be used to return a flat list of all content in the system for providing to a search engine, this is what the search seed is for. Where this is unavoidable, a paging component must be used to ensure that the menu does not consume too much memory and thus cause memory errors.
Optimising Navigator Components- Only select both 'Ancestors' and 'Descendents' if really necessary
- For unsecure sites (where content is accessed anonymously or always acc essed by the same user, eg. Administrator), set 'Maximum pages to include' and 'Pages to read ahead' to 1
Optimising Portal Personalization Rules- Avoid having too many rules based off authoring template elements as they don't perform as well as rules that utilise standard metadata (such as keywords and categories)
- Note: Short Text elements (available from WCM 6.1 onwards) are indexed by the J CR database and thus will perform like standard metadata
- Avoid using a PZN rule when a WCM Menu component can achieve the same result
- Consider enabling PZN rule caching which is discussed here: http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/pzn/pzn_resource_cache.html
Optimising WCM Versioning- Consider disabling 'Versioning' for all items on both authoring and rendering servers if it isn't required. It defaults to on.
- Versioning also has a performance impact on syndication if all items are being syndicated and also on authoring.
Optimising Authoring Templates- A well designed Authoring Template is a prerequisite to achieving optimal Web Content Management authoring performance and making the application easy to use for content creations. Special consideration must be given to choosing the number of elements for your Authoring Template, as each element in the template creates additional overhead when performing authoring actions.
- For optimal performance of authoring actions, it is recommended to limit the number of elements to 10 - 15 elements. Having templates larger than this will effect performance of key authoring functions.
Optimising WCM's Internal Caches- Web Content Management has various internal caches that store frequently accessed data fragments (not entire rendered pages). By default these caches have a maximum size of 2000 items, however during performance tuning (where any changes can be quantified in times of their % performance gain or decrease) you may want to try increasing the size of them:
- abspath (services/cache/iwk/abspath): Stores the path to sites, siteareas and content
- abspathreverse (services/cache/iwk/abspathreverse): Stores the path to sites, siteareas and content (in reverse)
- menu (services/cache/iwk/menu): Stores the results of cacheable Web Content Management menus
- nav (services/cache/iwk/nav): Stores the results of cacheable Web Content Management Navigators
- strategy (services/cache/iwk/strategy): Stores fragments of Web Content Management objects (ie. Provides a caching layer over the repository)
- summary (services/cache/iwk/summary): Stores summary information about Web Content Management objects (used throughout the Authoring UI and API
- site (services/cache/iwk/site): Stores resources that are smaller than the configured max cache object size, and is also used by the Pre-Renderer to cache pages (when the pre-renderer is configured as the default module) and by the old Connector architecture to store cached responses (if caching is enabled)
- missed abspath (services/cache/iwk/missed): Stores the path of the sites, siteareas and content that are known to not exist
- draft summary id (services/cache/iwk/draftSummary): Stores a map of Draft Summary Ids to their published object Ids - V6.1 only
- global (services/cache/iwk/global): Stores WCM Library objects indexed by their ID - V6.1 only
- libparent (services/cache/iwk/libparent): Stores a map of WCM Library Ids to their parent node Ids -V6.1 and Quickr Only
- The WAS extended cache monitor can also be used to view statistics about each cache such as the amount of hits, misses and the eviction count. The eviction count is an important statistic as it tells you how many entries were forcibly removed to make room for new entries. If the ratio of evictions to hits is high, then it indicates that this cache could benefit from its size being increased.
- To change the size of one of the above caches, follow the below steps:
- From the WAS Administration Console, navigate to the 'Resources \ Cache Instances \ Object Cache Instances' section
- Click the link representing the cache whose size you want to change
- Enter the new size and click 'Ok'
- Click the 'Save' link at the top of page
- Click the 'Save' button
- You will need to restart the server for the changes to take effect
- NOTE: If you have a cluster, then you may need to make this change to all nodes in the cluster
- WARNING: Increasing the size of the internal caches will cause the server to consume more memory and can cause out of memory errors and server crashes if the maximum heap size is set too low, the maximum cache size is set too high or if the maximum heap size is set so high that the operating system doesn't have enough memory to function (note that the database driver runs from operating system memory). For this reason, it's recommended to only increase the cache sizes while performing performance tuning and monitoring memory utilisation.
- To see information on WCM's End-User (ie. not-internal caches), see the 'Flushing and Monitoring Caches' section of Caching and Prerendering page
Optimising Applications that use the Web Content Management API- See this link for further information on optimizing applications that use the Web Content Management API
|
|
|
|
| Version 57 |
June 22, 2010 |
9:48:53 PM |
by David De Vos  |
|
|