problema de rendimiento

Estimado José

Antes que nada recuerda que .NET funciona por naturaliza desconectado. Esta
es una gran ventaja con respecto a Visual Studio V6.0, sin embargo tiene su
costo. Cada vez que hay un acceso a la base de datos es necesario abrir una
nueva conexión y esto en cualquier gestor de base de datos es un proceso
costoso (incluyendo a SQL Server), por esto ADO.net mantiene un pool de
conexiones y las reutiliza con mucha eficiencia. Este pool de conexiones
ocupa bastantes memoria en el cliente y recursos de servidor. Así que .NET
pone a disposición del programar una manera de forzar que las conexiones
sean eliminadas del pool para ahorrar recursos en caso de que se tenga
certeza de que la conexión no será utilizada nuevamente.

Sin embargo si cada vez que se habre una conexión, haces un llamado a
ReleaseObjectPool entonces matas el beneficio del pool de conexiones. La
moraleja es que tenes que revisar caso a caso si es justificado llamar a
ReleaseObjectPool en base a la lógica que te explicaba arriba. Si tu
aplicación no usará más esa conexión entonces está bien mandar a hacer
Release, pero si no, mejor deja que sea ADO a través del pool quien maneje
el período de vida de las conexiones.

saludos

Jorge González


"José Cordero" escribió en el mensaje
news:

Hola,
Tenemos una aplicación en producción en .NET funcionando con SQLServer
200.
Recientemente al subir una versión hemos notado una bajada de rendimiento
muy
grande y no se a que se puede deber. Buscando he encontrado que lo único
que
hemos cambiado es es que al cerrar cada conexión llamamos al método
ReleaseObjectPool(); sabe alguien si constantes llamadas a este método
puede
provocar la bajada de rendimiento.
Muchas gracias.

ReleaseObjectPool can be called to free resources that would otherwise be
reserved for pooled OleDbConnection objects. You might want to call this
method if, for example, the connection object will not be used again for
the
period of time that OLE DB services would normally keep pooled connections
active. Note that calling the method alone does not actually release the
active connections that exist in the pool.