5 The DB2 Data Provider : Performance Considerations

Performance Considerations
The performance of your application can be affected by the values you set for the following connection string options and properties.
Connection String Options
Array Send Size: The value for this option can be an integer from 1 to 4,294,967,296 (4 GB); the default is 4096 (4 MB). The value 1 is a special value that does not define the number of bytes but, instead, causes the data provider to allocate space for exactly one row of data. Larger values increase throughput by reducing the number of times the data provider fetches data across the network when retrieving multiple rows. Smaller values improve response time, as there is less of a delay waiting for the server to transmit data.
For example, if your application normally fetches 200 rows, it is more efficient for the data provider to fetch 200 rows at one time over the network than to fetch 50 rows at a time during four round trips over the network.
Cursor Description Cache: The data provider can cache cursor description information when requested to execute a Select statement that exactly matches a previously executed Select statement. Caching the cursor descriptions allows the data provider to optimize the execution of subsequent executions of the same statement, reducing the number of network round trips required. In this case, this option should be set to True. If the application does not execute the same Select statement repeatedly, this option should be set to False. Otherwise, performance is degraded because memory is used unnecessarily.
Cursors With Hold: Held cursors maintain their positions in the result set after a commit has been performed, for example, when you are using a DB2DataReader and you want to perform multiple commands on each row of the DataSet, committing after each command. For your application to use Held cursors, this option must be set to True. This behavior degrades performance; therefore, unless your application must use Held cursors, this option should be set to False.
Defer Prepare: By default, the DB2 data provider does not make a separate trip across the network at prepare time when executing prepared statements. If your application does not require result set information at prepare time, the data provider can improve performance when executing prepared statements by setting Defer Prepare to True.
Enlist: Although the DB2 data provider supports distributed transactions through this connection option, using distributed transactions impacts performance. Distributed transactions require additional logging and network round trips, making them up to four times slower than local transactions. If your application connects to only one database and you do not need to connect to another database, the data provider can improve performance if the Enlist connection option is set to False, thereby using local transactions.
Encryption Method: Data encryption can adversely affect performance because of the additional overhead (mainly CPU usage) required to encrypt and decrypt data.
Max Statement Cache Size: Caching all of the prepared statements that an application uses might appear to offer the best performance. However, this approach may come at a cost of database server memory if you implement statement caching with connection pooling. In this case, each pooled connection has its own statement cache, which may contain all of the prepared statements used by the application. All of the cached prepared statements are also maintained in the database server's memory.
Pooling: If you enable the data provider to use connection pooling, you can define additional options that affect performance:
Load Balance Timeout: You can define how long to keep connections in the pool. The pool manager checks a connection's creation time when it is returned to the pool. The creation time is compared to the current time, and if the timespan exceeds the value of the Load Balance Timeout option, the connection is destroyed. The Min Pool Size option can cause some connections to ignore this value.
Connection Reset: Resetting a re-used connection to the initial configuration settings impacts performance negatively because the connection must issue additional commands to the server.
Max Pool Size: Setting the maximum number of connections that the pool can contain too low might cause delays while waiting for a connection to become available. Setting the number too high wastes resources.
Min Pool Size: A connection pool is created when the first connection with a unique connection string connects to the database. The pool is populated with connections up to the minimum pool size, if one has been specified. The connection pool retains this number of connections, even when some connections exceed their Load Balance Timeout value.
Schema Options: Returning some types of database metadata can affect performance. To optimize application performance, the data provider prevents the return of performance-expensive database metadata such as procedure definitions or view definitions. If your application needs this database metadata, you can specifically request its return.
To show more than one type of the omitted metadata, specify either a comma-separated list of the names, or the sum of the hexadecimal values of the column collections that you want to return. For example, to return procedure definitions and view definitions, specify one of the following:
Schema Option=ShowProcedureDefinitions, ShowViewDefinitions
Schema Options=0x60
Statement Cache Mode: In most cases, enabling statement caching results in improved performance. To enable the caching of prepared statements (Command instances), set this option to Auto. Use this setting if your application has marked prepared statements for implicit inclusion in the statement cache, or has marked some statements for implicit inclusion and others for explicit inclusion. If you want the statement cache to include only prepared statements that are marked Cache, 1) set the StatementCacheBehavior property of the Command object to Cache and 2) set this option to ExplicitOnly.
Properties
BatchUpdateSize: If your application uses disconnected DataSets and updates those DataSets, you can positively influence performance by setting the BatchUpdateSize property of the DataAdapter object to a value greater than 1. By default, the data provider attempts to use the largest batch size possible. However, this may not equate to optimal performance for your application. The value you set depends on the number of rows you are typically updating in the DataSet. For example, if you are updating less than 50 rows, a suggested setting for this property is 25. If set to 0, the DataAdapter uses the largest batch size the data source can support. The UpdatedRowSource property for the UpdateCommand, DeleteCommand, and InsertCommand must be set to None or OutputParameters.
If set to 1, batch updating is disabled.
If set to a value greater than 1, the specified number of commands are executed in a batch. The UpdatedRowSource property for the UpdateCommand, DeleteCommand, and InsertCommand must be set to None or OutputParameters.
CurrentUserAffinityTimeout: Increasing the value of this property can increase the chances that a connection with the same CurrentUser exists in the pool. However, when set too high relative to other CurrentUserAffinityTimeout values, the connection pool might have to create new connections, which is more performance-expensive than reauthenticating an existing connection.
StatementCacheBehavior: If your application reuses prepared statements multiple times over an application’s lifetime, you can influence performance by using a statement cache. This property identifies how a prepared statement (a Command object instance) is handled during statement caching.
If set to Cache, the prepared statement is included in the statement cache.
If set to Implicit and the Statement Cache Mode connection string option is set to Auto, the prepared statement is included in the statement cache.
If set to DoNotCache, the prepared statement is excluded from the statement cache.
You can use connection statistics to determine the effect that caching specific statements has on performance (see “Analyzing Performance With Connection Statistics”).