Clone Connection If Needed: The data provider can clone the existing connection if another active result set (not all results fetched from an open DataReader) is not currently possible on the existing connection and the application requires one. If you want your application to run with multiple active result sets, this option must be set to True. This behavior degrades performance; therefore, unless your application must allow multiple active result sets, this option should be set to False.
Encryption Method: Data encryption can adversely affect performance because of the additional overhead (mainly CPU usage) required to encrypt and decrypt data.
Enlist: Although the Sybase 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.
Fetch Buffer Size: The data provider can limit the number of bytes of data to prefetch to the client when executing a statement that produces a result set. Fetch Buffer Size can limit the actual connection to one active result set if its value is not large enough to hold the entire result set. Using a very large number can have a negative effect on performance.
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.
Packet Size: Typically, it is optimal for the client application to use the maximum packet size that the server allows. This reduces the total number of round trips required to return data to the client application, thus improving performance. Therefore, the performance can be improved if the Packet Size connection string attribute is set to the packet size of the server.
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.
Select Method: In most cases, using server-side database cursors impacts performance negatively. Thus, set this option to Direct. However, if the following variables are true in your application, the best setting for this option is Cursor, meaning that server-side database cursors are used:
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.
Text Size: TEXT and IMAGE columns can contain very large amounts of data. In some instances, however, you may not need to display the entire value of each row of the column. For example, you may want to display only the first 500 characters of each row of a TEXT column, even though some of the values are much larger. In a case like this, you should set the Text Size option to the maximum amount of data that you want to retrieve instead of the size of the largest value in the column. Otherwise, performance is reduced by unnecessarily transferring large amounts of data. On the other hand, if you do want to retrieve the entire value of each row of the column, you must set this option accordingly so that the data you retrieve is not truncated. The default for this option is 1 MB. If your application retrieves more than 1 MB of data, the buffer size should be increased accordingly.
Tightly Coupled Transactions: Using tightly coupled transactions slows a connection because when locking occurs, the process on the server must communicate with other processes to determine whether locks held are held by other connections in the same distributed transaction. When tightly coupled transactions are not enabled, the overall performance of the data provider is better, but multiple connections within the same distributed transaction may hang each other because the connections do not obey each other’s locks.
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.
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.