moure.es – Alfonso Moure Ortega

En mi post anterior dedicado a las conexiones a base de datos desde ASP.NET comenté algunos de los problemas más comunes durante el diseño de arquitecturas software en ASP.NET y la gestión de conexiones con bases de datos, especialmente con Microsoft SQL Server.

Vimos que la solución final necesaria para poder utilizar conexiones en ASP.NET sin meternos en lios de memoria o conexiones compartidas, debíamos abrir y cerrar la conexión con la base de datos para cada consulta, pese a que pudiera parecer redundante o molesto.

Pero, si aplicais lo planteado en un proyecto a gran escala y con un buen tráfico de usuarios, notareis que no se sufre un impácto demasiado grande en el rendimiento de la aplicación pese a utilizar esta técnica, y esto se debe a una gran capacidad con la que cuenta SQL Server: el connection pooling: cuando llamamos a Close() para cerrar la conexión a la base de datos, ésta no se cierra, sino que queda almacenada en un listado de conexiones inactivas a las que puede recurrirse en cualquier momento.

Más adelante en nuestra misma aplicación, cuando llamemos a Open() para volver a conectarnos, ASP.NET y SQL Server colaborarán para localizar una conexión marcada como inactiva pero cuyo connection string coincida con la conexión que intentamos crear y activar. En el momento en que es localizada, esta es invocada y reactivada, evidanto de esta manera un malgasto de recursos extra al crear y abrir una conexión.

Una cosa debe quedarnos bien clara en cualquier caso: cualquier tipo de movimiento o trabajo con la base de datos, apertura o cierre de conexión con un proveedor, petición o inserción de datos, consume recursos temporales y de memoria del sistema, por lo que es de vital importancia el localizar nuevas vias de trabajo con datos y mejoras  en sus algoritmos como puntos clave para potenciar la eficiencia de nuestras aplicaciones.

Bookmark