Problemas de rendimiento y escalabilidad (¿No se les hacen conocidos?)
La siguiente es una lista de los problemas más comunes (inclusive más comunes de lo que pareciesen) que afectan enormemente al rendimiento y escalabilidad de la capa de datos en una aplicación.
-Queries ineficientes. Los queries que procesan y retornan más filas o columnas de lo necesario desperdician recursos del sistema que bien pueden ser aprovechados para servir otras peticiones. Peor aún si estos queries no toman ventajas de los índices existentes.
-Traer mucha información. Mucha información o data en los resultados, la mayoría de las ocasiones, es producida por consultas ineficientes. Un query con sentencia Select * usualmente provoca este problema. También vale la pena analizar la sentencia WHERE en las consultas para verificar que no se retornan muchas filas. Siempre se debe tratar de hacer la sentencia WHERE lo más específico posible.
-Indices ineficientes o no existentes. Los queries se dañan o degradan ante la inexistencia de índices dado que un “barrido” de la tabla (full table scan) debe ser ejecutado. Así, a medida que los datos van creciendo (como en todo sistema), las tablas pueden resultar fragmentadas. Aquí lo recomendables es tener un plan de reconstrucción de los índices, para evitar este escenario.
-“Round trips” innecesarios. No hay mucho que agregar. Un “round trip” siempre afecta al rendimiento o performance de la aplicación. Está pegado además al tráfico de la red y carga del servidor. Hay que tratar de mantener a los “round trips” lo mínimo posible.
-Muchas conexiones abiertas. Las conexiones son de por sí un recurso costoso, que debe ser compartido entre varios procesos utilizando “connection pooling”. Abrir una conexión por cada proceso limita terriblemente la escalabilidad. Evitemos tener conexiones abiertas y cadenas de conexión variantes.
-Liberación de recursos. Un problema común también resulta en la falta de liberación de recursos, lo que previene que sean reutilizados. Si no se cierran las conexiones antes que la conexión caiga fuera del alcance de la misma, no se libera mientras el objeto no se elimina de la memoria. Esto puede provocar presión sobre los recursos, lo que obviamente nos conduce a un problema.
-Abuso de transacciones. Si se escoge el tipo incorrecto de transacción, se puede añadir mucha latencia a cada operación. De igual manera, si mantenemos las transacciones abiertas por periodos largos de tiempo, resultará contraproducente. Si bien es cierto las transacciones son necesarias para asegurar la integridad de los datos, necesitas asegurarte que el tipo correcto de transacción está siendo utilizado.
-Mucha normalización. Esto puede provocar muchos joins entre las tablas. Obviamente afectará al rendimiento.
¿Cuántos tienes?
-Queries ineficientes. Los queries que procesan y retornan más filas o columnas de lo necesario desperdician recursos del sistema que bien pueden ser aprovechados para servir otras peticiones. Peor aún si estos queries no toman ventajas de los índices existentes.
-Traer mucha información. Mucha información o data en los resultados, la mayoría de las ocasiones, es producida por consultas ineficientes. Un query con sentencia Select * usualmente provoca este problema. También vale la pena analizar la sentencia WHERE en las consultas para verificar que no se retornan muchas filas. Siempre se debe tratar de hacer la sentencia WHERE lo más específico posible.
-Indices ineficientes o no existentes. Los queries se dañan o degradan ante la inexistencia de índices dado que un “barrido” de la tabla (full table scan) debe ser ejecutado. Así, a medida que los datos van creciendo (como en todo sistema), las tablas pueden resultar fragmentadas. Aquí lo recomendables es tener un plan de reconstrucción de los índices, para evitar este escenario.
-“Round trips” innecesarios. No hay mucho que agregar. Un “round trip” siempre afecta al rendimiento o performance de la aplicación. Está pegado además al tráfico de la red y carga del servidor. Hay que tratar de mantener a los “round trips” lo mínimo posible.
-Muchas conexiones abiertas. Las conexiones son de por sí un recurso costoso, que debe ser compartido entre varios procesos utilizando “connection pooling”. Abrir una conexión por cada proceso limita terriblemente la escalabilidad. Evitemos tener conexiones abiertas y cadenas de conexión variantes.
-Liberación de recursos. Un problema común también resulta en la falta de liberación de recursos, lo que previene que sean reutilizados. Si no se cierran las conexiones antes que la conexión caiga fuera del alcance de la misma, no se libera mientras el objeto no se elimina de la memoria. Esto puede provocar presión sobre los recursos, lo que obviamente nos conduce a un problema.
-Abuso de transacciones. Si se escoge el tipo incorrecto de transacción, se puede añadir mucha latencia a cada operación. De igual manera, si mantenemos las transacciones abiertas por periodos largos de tiempo, resultará contraproducente. Si bien es cierto las transacciones son necesarias para asegurar la integridad de los datos, necesitas asegurarte que el tipo correcto de transacción está siendo utilizado.
-Mucha normalización. Esto puede provocar muchos joins entre las tablas. Obviamente afectará al rendimiento.
¿Cuántos tienes?
