Conceptos clave para optimizar la plataforma de BI 4 de SAP BusinessObjects

Rep-up-graph

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.

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:

• El grupo de conexiones Es configurable en el CMC. El valor predeterminado es 14 pero puede configurarse a 50. El grupo de conexiones acelera los tiempos de conexión entre el usuario y el servidor. Por lo tanto, es una buena práctica establecer este valor en 50 siempre que sea posible
• CMS utiliza una huella de 1 GB de memoria. Cada objeto está alrededor de 10 kb más o menos. Compruebe en el CMC el número de objetos y considere aumentar el valor para objetos máximos en caché Si es posible (esto aumentará la huella de memoria del CMS).
• Escala de CMS . Generalmente un CMS espera tener 400 usuarios pesados. Para equilibrar la carga, agregue un nuevo CMS cada 500 usuarios.
• No apile más de 1 CMS en el mismo sistema físico.
• Colocar las bases de datos del repositorio (Bases de datos del sistema y de auditoría) junto al CMS. CMS está haciendo muchas consultas a estas bases de datos, insertar y actualizaciones.

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:

• Coloque el IFRS junto a los servidores de procesamiento , Por lo que todas las solicitudes de una plantilla de informe no necesitan recorrer una amplia red para encontrarlas.
• Limitar el número de instancias en trabajos de planificación para la optimización de OFRS . Sin límites de instancia, es posible tener miles de instancias de informe. Esto está afectando a la OFRS, ya que aumenta la complejidad de la estructura de instancias, por lo que cuando un usuario solicita una instancia de un informe que hace que el OFRS más lento al tratar de encontrarlo.