Buen día a todos,

Esta es mi primera participación en este blog y estoy muy entusiasmado en pertenecer a la comunidad de bloggers de AX en Latinoamérica. Mis temas van a estar principalmente relacionados a arquitectura y performance de AX.

El día de hoy voy a platicar un poco sobre las bases del performance en una arquitectura de AX y algunas configuraciones que en nuestra experiencia causan problemas de performance en AX:

-          Dedicar un servidor a cada uno de los componentes de AX: muchas veces vemos que el servidor de SQL Server tiene también instalada una instancia de AOS o incluso es un controlador del dominio (DC). Esta no es una práctica recomendable, pues los diversos componentes compiten por los recursos del servidor (memoria, procesador, disco, etc.) y normalmente uno de ellos, o todos, tienen un performance inadecuado.

-          Se deben separar los ambientes de producción y de pruebas: los ambientes de pruebas suelen ser inestables, sobre todo si la implementación de AX sigue en proceso de desarrollo, por lo tanto es importante evitar que el ambiente de producción sufra las consecuencias de pruebas insatisfactorias que incluso podrían causar caídas de los servidores.

-          Aprovechar la tecnología de 64-bit: AX 2009 funciona a 64-bit que es una característica muy valiosa pues mejora los tiempos de procesamiento y la utilización de la memoria, considero que no hay razones para siquiera considerar una plataforma 32-bit cuando se decide la arquitectura para AX 2009. En AX 4.0, aunque no tenemos soporte de 64-bit a nivel de la aplicación, al menos podemos considerar que el servidor para SQL Server si sea a 64-bit, esto es completamente soportado y proporcionará una mejora importante en el rendimiento de una implementación de AX 4.0.

-          Repartir la carga de los distintos AOS: Cuando se tienen diversas instancias de AOS, es necesario monitorear que la carga de trabajo de todas las instancias se reparta equilibradamente y que no haya una instancia particularmente sobrecargada. Yo normalmente trató de pensar en dos tipos principales de carga en un cliente: los trabajos del día a día de los usuarios que por sí mismos no utilizan demasiados recursos del sistema, pero que debido a su volumen pueden generar un uso alto de los recursos de un servidor de AOS en un horario determinado y aquellas actividades “pesadas” que tienen un impacto general en el sistema cuando se ejecutan, ejemplos de esto serian el recalculo y cierre de inventarios, planeación maestra, etc. Como practica general, se recomienda que estas actividades pesadas se ejecuten en servidores AOS diferentes a los AOS que atienden a los clientes. También es importante conocer la funcionalidad de balanceo de cargas (cluster) incluida en AX y configurarla cuando se considere que se tendrá un beneficio en su uso.

Creo que con estos puntos cierro mi participación del día de hoy. Háganme llegar los temas de los que quieren que platiquemos.

Ah! Les recuerdo a mis amigos de Bogotá que estaremos dando un curso por allá la próxima semana (del 8 al 10 de noviembre), no falten.

Que tengan una buena semana!

Javier López | Ingeniero de Soporte para Dynamics AX