/ hybris

hybris performance

El performance en una aplicacion de hybris es muchas veces ignorado hasta que existe un problema en produccion, aqui describimos algunos puntos a considerar para que no tengas problemas en tus siguientes temporadas altas

Muchas veces se asume que los sistemas simplemente funcionan, pero la cantidad de usuarios y la frecuencia de las visitas tambien pueden generar problemas

Aqui describiremos algunos de los puntos a considerar para prepararse para un evento importante, ya sea una promocion, evento nacional como el hot sales, etc.

mantenimiento

Muchas veces pensamos que el mantenimiento es porque directamente el programador hizo algo mal, pero si expandemos esta perspectiva, a veces es necesario sacar un parche o un feature lo antes posible, esto hace que el equipo tenga menos tiempo para realizar verificacion de calidad en el codigo a mas bajo nivel, por lo tanto, es totalmente recomendable realizar mantenimiento constante a la aplicacion, no solo para reparar bugs, si no tambien, para el refactor continuo. esto permitira verificar soluciones, documentar codigo, mejorar la legibilidad (y por ende la mantenibilidad) del software

consumo de recursos en admin servers

Es aqui donde viven muchos procesos en segundo plano, trata de inhabilitar cronjobs innecesarios o de menor prioridad. Es importante entender que seguramente habra mayor frecuencia de replicacion de informacion (precios, inventarios, actualizaciones de ordenes, por mencionar algunos), y se espera que el servidor las pueda soportar

consumo de recursos en storefront servers

Hay muchas propiedades y configuraciones que podrian mejorar el tiempo de respuesta del servidor:

  • CDN
  • Habilitar cache de CMS
  • Minificado de CSS / JS
  • Compresion de CSS / JS

configuracion de web server

Muchas veces, los implementadores sugieren utilizar un CDN como un silver bullet para una carga mas rapida del sitio, cuando esto es cierto para contenido estatico, sin embargo, el HTML depende casi siempre de la sesion (carrito de compras, precios, inventarios, etc.), por ende, aun hay mucha dependencia de lo que podamos hacer desde nuestros web servers (WS) para tratar de hacer los despachos de peticiones mas eficientes:

  • Habilitar black list para robots que se conocen en la industria como maliciosos / innecesarios para SEO (recomendamos tambien ver nuestro post sobre seguridad web)
  • Compresion de contenido
  • Max threads
  • Verificacion de redirects internos
  • Remover capa de seguridad dentro de la infraestructura, por ejemplo, mantener HTTPS hasta el balanceador y utilizar HTTP dentro del resto (WS, app server)

configuracion del GC

Es sumamente importante entender que no hay un silver bullet para la configuracion del Garbage Collector (GC), por ende, este es un constante tuning, especialmente si hemos estado agregando / modificando funcionalidades

Si bien es cierto que muchas partes importantes del uso de la memoria recae en la codificacion (por ejemplo, utilizacion de wrapper classes en lugar de un tipo primitivo), tambien la configuracion de la estrategia para recolleccion de basura puede tomar tiempo. Este proceso requiere recursos, este limpiado de datos no sucede con magia, finalmente el GC debe realizar una verificacion sobre la memoria utilizada para saber si esta puede ser removida del ella, esto quiere decir, que si tenemos muchos objetos, el GC tardara consecuentemente mas tiempo, tambien se puede intuir, que si tenemos una cantidad muy grande de memoria y configurado el GC para correr periodicamente en frecuencias de tiempo muy distantes, la cantidad de informacion en memoria a checar sera demasiada, asi que este tomara mas tiempo y recursos

En muchas implementaciones hemos observado problemas con el consumo de CPU cuando entra el GC o problemas con la memoria reservada para el uso del GC, algunos puntos claves a considerar:

  • SAP CX / hybris recomienda una cantidad grandisima de reserva para la memoria de la aplicacion, esta recomendacion es un tanto agresiva, es mejor comenzar ligero, por ejemplo: 60% de memoria reservada para la aplicacion, esto permitira que podamos medir durante las pruebas / uso en PRD cuanto es el minimo necesario para mantener una carga determinada sin que el sistema operativo se quede sin memoria libre
  • Comparar estrategias del GC, por ejemplo G1 con frecuencias cortas y Mark-And-Sweep. Es bueno tener perspectivas del uso de cada algoritmo para distintos escenarios, por ejemplo podriamos encontrar que para nuestra carga es mejor utilizar uno en el dia a dia y otro funciona mejor dias de cargas importantes

hardware

Las soluciones a problemas de carga / performance en el sitio no se solucionan simplemente agregando mas fierro (hardware) a los servidores (escalamiento vertical)

En nuestra experiencia, es mucho mejor encontrar un sweet spot para cada caja y simplemente agregar nuevos nodos al cluster (escalamiento horizontal), esto hace mas facil de controlar el hardware e instancias de la aplicacion que se necesiten entre fechas, por ejemplo, si en Diciembre sabemos que tendremos alto consumo, podemos agregar un par de nodos mas y los removemos en cuanto veamos una decaida en el trafico. Esto tambien hace la vida del devops mas sencilla

desiciones inteligentes

Hoy en dia hay demasiados frameworks para hacer machine learning / analisis de datos, por lo que es ridiculo que no comencemos a utilizarlos. No estoy hablando de utilizar una herramienta que va a predecir el futuro al 100%, eso no existe (por mas que las empresas traten de vender lo contrario), no hay el mejor chatbot, el mejor motor de recomendaciones, el mejor analizador de sentimientos y definitivamente los analiticos del sitio no cuentan toda la historia

La posicion de analista de datos e ingeniero de machine learning son escenciales hoy en dia en las empresas, este tipo de perfiles, ayudaran al negocio a tomar desiciones educadas y no basados en la experiencia pura de una persona, donde la responsabilidad del escalamiento recae en una sola persona de estrategia, esto permite introducir justificaciones para hacer un analisis de riesgos con mayor sentido

Con estas herramientas / tecnicas, podemos realizar regresiones no solo para predecir la cantidad de trafico esperada, si no tambien, en base a los parametros de las pruebas, tratar de predecir si cierto tuning funcionaria en base a pruebas / experiencias pasadas (con suficiente informacion) e incluso comenzar a medir la cantidad de issues o areas con problemas obtenidos por evento / release

conclusiones

Existen muchas areas para realizar las pruebas y analisis para un tuning mas cercano a lo que el sitio necesita, no hay una sola solucion a los problemas, cada solucion cuenta con parametros distintos

Hoy en dia, hay muchas herramientas para hacer predicciones sobre el uso del sitio que pueden brindar apoyo al equipo de tecnologia para prepararse de forma mas adecuada