La plataforma SAP BusinessObjects (BO) BI 4 ha venido con muchas mejoras que han hecho que el sistema sea más complejo. Nosotros, como administradores de BI 4, debemos saber cómo funciona esta aplicación para poder aplicar las mejoras de optimización adecuadas a la plataforma, cuando sea necesario. En este artículo del blog, cubriremos los conceptos más importantes que deben considerarse como un primer paso para aumentar el rendimiento de la plataforma de BI. Es muy importante que un buen diseñador entienda los niveles conceptuales en la Plataforma de BI: Nivel de aplicación , Nivel de inteligencia y nivel de procesamiento. Nos referiremos a cada uno de ellos y daremos algunos consejos de optimización.
Optimización del nivel de aplicación (nivel web)
BI 4 se establece con la aplicación web Tomcat 7 cuyo componente de servidor tiene un http incorporado que también permite procesar contenido estático; Sin embargo, un servidor web dedicado, como Apache, permite alojar contenido estático y, por tanto, equilibrar los componentes web a procesar.
By adding a standalone Apache web server and using the wdeploy in split mode, we can improve navigation speed 25% or more. This can be done also in the same machine where the tomcat server is located. There is a dedicated article about how to do this and it can be found here: http://scn.sap.com/docs/DOC-6191
Por otro lado, Java 7 ofrece mejoras interesantes, como recolector de basura y arranque más rápido para la CPU de varios núcleos. Aunque el uso de JAVA 7 parece ser una prioridad en la hoja de ruta 4.2, mientras tanto es una buena práctica ser generoso cuando se aumenta el pool de memoria de tomcat siempre que sea posible.
Optimización en el nivel de procesamiento
El servidor de procesamiento adaptativo (APS) alberga más de 20 servicios y es basado en java, y la JVM utilizando Java 6. Por lo tanto, es limitado en términos de recolección de basura, por lo tanto, tenemos necesidades en términos de asistente de configuración del sistema, con el fin de dividir el APS en contenedores separados, haciendo la gestión de la APS más fácil. De forma predeterminada, el APS viene como una sola instancia con todos los servicios y con un montón de java máximo de 1 GB. Esto podría ser bueno para un desarrollo pequeño o un sistema de demostración, pero no es ideal para un sistema de producción real: la división de APS ayuda a la solución de problemas y la contención de problemas.
Podemos duplicar o crear nuevos APS en nuevos nodos para aumentar la potencia y hay dos maneras de hacer esto:
- Clonar el servidor APS existente y eliminar los servicios no necesarios
- Crear un nuevo servidor y agregar los servicios necesarios
Ambas opciones son buenas y dependerá de cómo sea reutilizable la configuración del APS, pero el resultado es el mismo. A pesar de que puede tener configuraciones distintas, es una buena práctica tener siempre al menos un APS con TODOS los servicios incluidos, si se detiene / deshabilita, los servicios básicos de APS siempre son necesarios.
Hay muchos enfoques al configurar APS y podríamos escribir decenas de artículos sobre él. El mejor enfoque es siempre el que mejor se ajuste a las necesidades del cliente, qué herramientas tienen, qué fuentes, etc. Lo más importante es identificar los cuellos de botella y hacer el mejor diseño para evitarlos.
An SAP article explains in more in detail all these approaches for sizing the APS and can be found in http://scn.sap.com/docs/DOC-31711. For example:
- Cómo clonar APS o cómo crear y configurar uno nuevo.
- Agregue un APS dedicado para el servicio de puente DLS para optimizar BICS para la inteligencia web.
- Crear un APS dedicado para el índice de búsqueda.
- Crear un APS dedicado para el análisis.
Podemos resumir algunas de las mejores prácticas de la siguiente manera:
- Es una buena práctica dividir el APS por producto.
- Acerca de JAVA montón tamaño:
- Ajustar -xms (inicial) y -xmx (máximo) al mismo valor aumenta la previsibilidad.
- Problema: JVM no puede compensar si se toma una mala decisión.
- Asignar un montón suficiente cuando sea posible:
- Es el factor de rendimiento para el proceso basado en BI java.
- Starving APS funciona mal, ya que intercambia la memoria en disco.
- Placing monitoring and auditing services in same APS makes good sense (APS hosts the monitoring service). Historical trending data can be stored in the same database instance. Monitoring is key in identifying bottlenecks and knowing more about the BO performance. An excellent article about how to use monitoring can be found in http://juancaruiz.com/clariba/introduction-to-cmc-monitoring-in-sap-bo4-sp4/
- Índice de búsqueda. Después de la instalación, construya el ámbito para el índice de búsqueda gradualmente. No incluya detalles innecesarios porque puede ralentizar el rendimiento. Por lo tanto, es bueno mejorar el índice de búsqueda sólo una vez que esté seguro con el sistema.
- Ajustar -xms (inicial) y -xmx (máximo) al mismo valor aumenta la previsibilidad.
Nivel de inteligencia
Para la plataforma de BusinessObjects, CMS es el cerebro. Metadatos de actualizaciones de CMS, verifica la seguridad y básicamente interactúa con la base de datos del sistema, que es clave para el rendimiento general de la plataforma. Cada operación está afectando la base de datos del sistema, y por lo tanto podría convertirse en un cuello de botella si no está bien configurado.
Criterios clave para la configuración de CMS:
- The connection pool is configurable in the CMC. The default value is 14 but can be set up to 50. The connection pool speeds up connection times between the user and the server. So it is good practice to set this value to 50 whenever is possible
- CMS uses a footprint of 1GB of memory. Each object is around 10kb plus or minus. Check in the CMC the number of objects and consider increasing the value for max objects in cache if possible (this will increase the memory footprint of the CMS).
- Scaling CMS. Generally one CMS expects to have 400 heavy user. In order to balance the load, add a new CMS every 500 users.
- No apile más de 1 CMS en el mismo sistema físico.
- Place repository databases (system and audit databases) next to the CMS. CMS is doing many queries to these databases, insert and updates.
Otros servidores que deben ser considerados son los Servidores de Repositorio de Archivos: IFRS (File Input Repository Server), que almacena todos los documentos y objetos de programa publicados en la plataforma y el Servidor de Repositorio de Archivos de Salida (OFRS), que almacena todas las instancias generadas por sistema. Hay algunas consideraciones que podemos aplicar para mejorar el rendimiento de estos servidores:
- Place the IFRS next to processing servers, so all the requests for a report template don’t need to go around a wide network to find them.
- Limit the number of instances on schedule jobs for optimization of OFRS. Without instance limits, it is possible to have thousands of report instances. This is impacting the OFRS since it increases the complexity of the instances structure, so when a user requests an instance of a report it makes the OFRS slower when trying to find it.