Oracle9iAS Personalization Administrator's Guide Release 9.0.1 Part Number A87539-02 |
|
This appendix contains information about tuning and configuring OP for your installation. You should read this appendix in conjunction with Chapter 7.
Installation and configuration of a recommendation engine (RE) must be tailored to the expected number of active users that it will support. The RE in this context refers to a single engine on a single database instance. If multiple engines are installed on the same database instance, the configuration parameters will require adjustment.
Many factors go into the optimization of an RE. Some of these are set by the installation procedure, while others are techniques that may be used by the DBA. Configuration options fall into two broad categories: System availability and performance. System availability consists of settings required by the RE to handle user load without failure. Performance includes those that help maximize throughput.
The system availability settings for RE configuration are dependent on the number of anticipated users. Given this, it is possible to estimate the approximate system resource requirements and make database configuration recommendations. Since the REAPI maintains a connection pool of user connections, which can be reused, the number of required connections depends on how well user requests are being satisfied by the RE. That is, if for some reason there is a slowdown in the RE causing connection links to be held longer in the REAPI connection pool, the number of connections will tend to increase. As the number of connections increases, the number of actual database sessions increases. Each connection in the REAPI connection pool represents a database session.
The maximum number of connections in the REAPI connection pool is a configurable parameter in each RE. If this limit is exceeded, it may indicate that there are performance issues that need to be addressed other than simply increasing the size of the connection pool.
Each user's client session results in database activity in the RE schema. As such, first configure the database to handle the number of anticipated users. Depending on the amount of available memory and CPUs in the system the RE database is installed on, it may be possible to support 50-100 users in a dedicated server environment. In this environment, each user connection to the database would require its own dedicated Oracle server for database access. As the number of users extends beyond 100, it may be more appropriate to use Oracle's Multi-Threaded Server environment where database connections are pooled and serviced by shared database servers. The DBA responsible for the RE must decide whether the dedicated or shared server environment is used.
REAPI performance may be affected by several factors. On the client side, the REAPI runs in the JServer environment. Sufficient memory and CPU must be available to the client to handle the throughput for the active users. Communication with the RE from the REAPI clients is implemented through JDBC connections over Oracle's SQL*Net network. As the number of users grows, so does the demand on the network.
The recommendation engine requires certain database parameters to be set to a minimum value, as follows:
JOB_QUEUE_PROCESSES=2
The parameters listed below, while not necessary, are strongly recommended. Recommended sizes are also indicated:
BUFFER_POOL_KEEP |
50 @ 8192 bytes ea |
SORT_AREA_SIZE |
819200 bytes |
SORT_AREA_RETAINED_SIZE |
819200 bytes |
The table below suggests guidelines for database configuration parameters based on number of projected users. The table shows, for a specified number of users, whether multi-threaded servers (MTS) are recommended, and recommended values for the number of MTS dispatchers, shared MTS servers, sessions, the size of large pool, and the size of shared pool:
The following table suggests guidelines for recommendation engine configuration settings based on the number of project users. These parameters are set in the RE schema table RE_CONFIGURATION. The table shows, for a specified number of users, the recommended connection pool size and data synchronization interval:
Users |
ConnectionPoolSize (number of connections) |
DataSyncInterval (in seconds) |
---|---|---|
100 |
128 |
300 |
1000 |
256 |
300 |
2000 |
512 |
300 |
3000 |
1024 |
180 |
4000 |
2048 |
180 |
The Mining Table Repository (MTR) database holds customer and product data. Data mining models are built based on this data. If the MTR has been configured by the administrator to permit data synching from the RE, data collected in the RE will be copied to the MTR at scheduled intervals. Customer profile data is also copied from the MTR into the RE when a customer begins a user session. All data transfer between the MTR and the RE is done using database links.
The following table offers guidelines for database configuration parameters based on the number of projected users. The table shows, for a specified number of users, whether multi-threaded servers (MTS) are recommended, and recommended values for the number of MTS dispatchers, the number of MTS servers, the number of sessions, and the size of the large pool:
Users | MTS | MTS Dispatchers | MTS Servers | Sessions | Large Pool |
---|---|---|---|---|---|
100 |
No |
N/A |
N/A |
100 |
Default |
1000 |
Yes |
2 |
10 |
100 |
25M |
2000 |
Yes |
3 |
20 |
200 |
50M |
3000 |
Yes |
4 |
20 |
300 |
100M |
4000 |
Yes |
50 |
30 |
400 |
150M |
|
Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|