Como reducir round trips
En la entrada anterior veíamos que una de las causas comunes de degradación del performance es el uso de muchos round trips en las páginas ASP.NET. Utilizando los siguientes tips, podríamos reducir su uso –y abuso-.
En medida de lo posible, agrupemos las sentencias SQL. Fallas en este sentido crean viajes adicionales –e innecesarios- a la base de datos. Pueden agruparse sentencias SQL separándolas con un punto y coma (;) o utilizando un stored procedure que ya lo haga. Los resultados se los puede ir leyendo con un objeto DataReader, con el método NextResult.
Para evitar round trips, se puede utilizar “connection pooling”. Al reutilizar las conexiones desde un pool, se evita los round trips que son necesarios debido al establecimiento de la conexión como tal y la autenticación. En esto podríamos ahondar un poco más en el futuro.
No retornar datos innecesarios. No me cansaré de repetirlo. Es absurdo. Si necesitamos un dato sencillo, podríamos utilizar el método ExecuteScalar. De igual manera se puede utilizar la sentencia ExecuteNonQuery, si queremos ejecutar sentencias de definición de datos (DDL), como la sentencia CREATE TABLE. Esto ayuda también a reducir el costo de crear el conjunto de resultados.
Se puede utilizar el caché (caching) para mantener los datos cerca del cliente en lugar de ir a la base en cada round trip.
Hay que tener cuidado de los round trips implícitos. Estos se producen en las operaciones que extraen metadata de la base de datos. Por ejemplo, deberíamos evitar el método DeriveParameters si ya conocemos información sobre los parámetros. Es mucho mejor –y eficiente- llenar la colección de parámetros explícitamente. La siguiente línea de ejemplo muestra una llamada que causa un round trip explícito.
SqlCommandBuilder.DeriveParameters(cmd)
En medida de lo posible, agrupemos las sentencias SQL. Fallas en este sentido crean viajes adicionales –e innecesarios- a la base de datos. Pueden agruparse sentencias SQL separándolas con un punto y coma (;) o utilizando un stored procedure que ya lo haga. Los resultados se los puede ir leyendo con un objeto DataReader, con el método NextResult.
Para evitar round trips, se puede utilizar “connection pooling”. Al reutilizar las conexiones desde un pool, se evita los round trips que son necesarios debido al establecimiento de la conexión como tal y la autenticación. En esto podríamos ahondar un poco más en el futuro.
No retornar datos innecesarios. No me cansaré de repetirlo. Es absurdo. Si necesitamos un dato sencillo, podríamos utilizar el método ExecuteScalar. De igual manera se puede utilizar la sentencia ExecuteNonQuery, si queremos ejecutar sentencias de definición de datos (DDL), como la sentencia CREATE TABLE. Esto ayuda también a reducir el costo de crear el conjunto de resultados.
Se puede utilizar el caché (caching) para mantener los datos cerca del cliente en lugar de ir a la base en cada round trip.
Hay que tener cuidado de los round trips implícitos. Estos se producen en las operaciones que extraen metadata de la base de datos. Por ejemplo, deberíamos evitar el método DeriveParameters si ya conocemos información sobre los parámetros. Es mucho mejor –y eficiente- llenar la colección de parámetros explícitamente. La siguiente línea de ejemplo muestra una llamada que causa un round trip explícito.
SqlCommandBuilder.DeriveParameters(cmd)
