Acerca de los resultados de rendimiento
El sistema utilizado para las pruebas es un cluster extendido de Oracle Fusion Middleware (FMW) configurado en las regiones de Oracle Cloud Infrastructure (OCI) de Fráncfort y Ámsterdam.
El dominio WebLogic consta de 5 nodos distribuidos en distintas ubicaciones para permitir comparaciones de rendimiento de varias topologías: servidores que se ejecutan en el mismo dominio de disponibilidad que la base de datos, servidores en la misma región pero en distintos dominios de disponibilidad y servidores ubicados en una región diferente.
Estas pruebas de esfuerzo se realizaron utilizando la demostración de órdenes de SOA Fusion (FOD) como una aplicación SOA de ejemplo. La demostración de FOD se ha modificado para insertar mensajes de Java Message Service (JMS) en un destino de destino distribuido uniforme (UDD) cuando se completa una orden. Este ejemplo hace un uso intensivo de la base de datos y utiliza varios adaptadores SOA, como el adaptador de archivos y el adaptador de JMS. También implica diferentes componentes de SOA, como Mediator, Business Process Execution Language (BPEL), el motor de reglas y varias funciones WebLogic.
En el siguiente diagrama se muestra el entorno de cluster ampliado de FMW utilizado para las pruebas:
fmw-stretched-performance-env-oracle.zip
Los valores reales de latencia entre las redes en este entorno fueron:
| Entre hosts | Latencia de Avgerage (RTT en ms) |
|---|---|
| En el mismo dominios de disponibilidad | 0.3 |
| En la misma región, pero en un dominio de disponibilidad diferente | 0.6 |
| En diferentes regiones (Fráncfort y Ámsterdam) | 6.5 |
Revisar pruebas de estrés
Algunas de las configuraciones probadas fueron:
- Destacando el cluster con dos nodos activos, aplicando diferentes latencias entre los servidores y entre uno de los servidores a la base de datos.
- Prueba de esfuerzo de servidores individuales, cada uno con diferentes latencias para la base de datos.
- Ejecución de pruebas con ambos servidores ubicados con la base de datos (solo local) y con ambos servidores ubicados de forma remota desde la base de datos (solo remota).
- Destacando el cluster con dos nodos activos en cada región.
Para cada configuración, se probaron diferentes cargas de trabajo. Todas las solicitudes de carga de trabajo se envían primero al front-end, donde se distribuyen (mediante el equilibrio de carga global, los equilibradores de carga locales y, a continuación, los servidores web) entre las instancias de Oracle WebLogic Server. La categoría de carga de trabajo (baja, media, alta) depende del número de nodos activos de cada configuración y está limitada por los límites de simultaneidad de la base de datos. Por ejemplo, 80 usuarios virtuales simultáneos se considerarían una carga de trabajo baja para los servidores WebLogic si hay cuatro nodos en ejecución, pero una carga de trabajo alta si solo hay un nodo activo. Sin embargo, desde la perspectiva de la base de datos, la carga de trabajo sigue siendo la misma. Para simplificar, las cargas de trabajo utilizadas son las siguientes:
- Cargas de trabajo bajas (20 usuarios virtuales simultáneos por servidor WebLogic, con un máximo de 40 usuarios virtuales simultáneos en el sistema)
- Cargas de trabajo medianas (40-60 usuarios virtuales simultáneos por servidor WebLogic, con un máximo de 120 usuarios virtuales simultáneos en el sistema)
- Cargas de trabajo altas (80 usuarios virtuales simultáneos por servidor WebLogic, con un máximo de 160 usuarios virtuales simultáneos en el sistema)
En base a los resultados de las pruebas de esfuerzo, estas son las conclusiones:
- Rendimiento general del cluster
Rendimiento general del clúster (en términos de rendimiento WebLogic, transacciones por segundo [TX/seg]) para un clúster con 2 servidores:
- Cuando ambos servidores se encuentran en el mismo dominio de disponibilidad (AD) (tomado como referencia): 100%
- Cuando cada servidor está en un dominio de disponibilidad diferente: ~100%
- Cuando un servidor está en una región diferente (6.5ms tiempo de ida y vuelta (RTT)): del 90 al 95 %
- Cuando ambos servidores están en una región diferente a la base de datos (6.5ms RTT): 85-95%
- Rendimiento por servidor
El rendimiento por servidor (en términos de rendimiento WebLogic, TX/s):
- Para el servidor en el mismo dominio de disponibilidad que la base de datos (tomado como referencia): 100%
- Para el servidor en el otro AD: 98-99%
- Para el servidor en la otra región: 85-90%
- Número de conexiones de origen de datos activas
El número de conexiones de origen de datos activas aumenta con una mayor latencia en la base de datos. Aunque depende de la carga de trabajo, el servidor de la región 2 muestra hasta 2x conexiones activas que el servidor con la base de datos. Considere esto para obtener un tamaño correcto de los orígenes de datos WebLogic y las sesiones de base de datos.
- Transacciones de JTA
Las transacciones de JTA permanecen activas durante períodos más largos en servidores con mayor latencia en la base de datos. Es más probable que las transacciones que permanecen activas durante períodos más largos se vean afectadas por fallos. Por lo tanto, resulta especialmente importante en estos sistemas que los logs de transacciones utilicen almacenes persistentes JDBC. Para los fallos del servidor, se debe realizar la migración del servicio y la recuperación se realizará automáticamente.
- Latencia entre regiones
Para una latencia entre regiones de 6.5ms RTT y la implementación de las mejores prácticas proporcionadas por este documento para los clusters de FMW Stretched:
- Hay una degradación de bajo rendimiento mediante un cluster estirado (~10%).
- Un cluster con un servidor en cada región y un cluster con ambos servidores en la región remota sufren una degradación similar del rendimiento. Esto se debe a que la comunicación entre clusters también se ve afectada por la latencia.
- Latencia entre dominios de disponibilidad
La latencia entre dominios de disponibilidad (0.6ms) no tiene un impacto significativo en el rendimiento general de un sistema SOA FOD.
Note:
Teniendo en cuenta todo lo anterior y con las penalizaciones de rendimiento observadas en muchas pruebas, Oracle no soporta clusters ampliados de Oracle Fusion Middleware que superen los 10 milisegundos de latencia (RTT) entre los sitios. Los sistemas pueden funcionar sin problemas, pero los tiempos de transacción aumentarán considerablemente. Las latencias superiores a 10 milisegundos (RTT) también causarán problemas en el cluster de Oracle Coherence utilizado para el despliegue y JT, los servicios web o los timeouts de aplicación. Esto hace que las soluciones presentadas en este manual sean adecuadas principalmente para sitios o regiones con baja latencia entre ellos.
Cuando se estresa un cluster con 2 nodos, el siguiente gráfico muestra el rendimiento general del cluster, según dónde se encuentren los servidores. La referencia (100%) es cuando ambos servidores se ejecutan en el mismo dominio de disponibilidad que la base de datos.
Al realizar un esfuerzo en un cluster con 2 nodos, el siguiente gráfico muestra el rendimiento del servidor que no está asociado a la base de datos (está en el otro dominio de disponibilidad o en una región remota) en comparación con el rendimiento del servidor que está asociado a la base de datos:
Cuando se estresa un cluster con 2 nodos, estos gráficos muestran el número de conexiones de origen de datos activas (promedio) para cada servidor. Un servidor siempre está colocado con la base de datos (site1) y el otro servidor está en valores de latencia diferentes de la base de datos (site2):
Al realizar un esfuerzo en un único servidor con diferentes latencias de base de datos, se observan los siguientes resultados de rendimiento, en comparación con un servidor que está en la misma ubicación que la base de datos, con una carga de media a alta. La referencia (100%) es cuando el servidor está en el mismo dominio de disponibilidad que la base de datos.
Al realizar un esfuerzo de un único servidor con diferentes latencias en la base de datos, se trata de las conexiones de origen de datos activas con un esfuerzo de medio a alto:
Al realizar un esfuerzo en un único servidor con diferentes latencias en la base de datos, la siguiente imagen muestra el tiempo medio activo de JTA para las diferentes latencias en la base de datos:
Al comparar el rendimiento de un cluster con ambos servidores de la misma región que la base de datos (solo local) frente a un cluster con ambos servidores de una región diferente a la base de datos (solo remota), se observan los siguientes resultados de rendimiento. La referencia (100%) es el cluster solo local.
En la siguiente figura, se muestra el tiempo medio activo de JTA TX para un cluster con ambos servidores ejecutándose en la misma región que la base de datos (solo local) y un cluster que ejecuta ambos servidores en una región diferente a la base de datos (solo remota).
Horas de inicio para revisión
Se esperan diferentes retrasos según la configuración de capacidad inicial en las fuentes de datos. Por defecto, la mayoría de los orígenes de datos de Oracle Fusion Middleware (FMW) utilizan una capacidad inicial cero para su pool de conexiones. Sin embargo, para reducir el tiempo de respuesta del sistema durante el funcionamiento normal en tiempo de ejecución, puede ser beneficioso aumentar la capacidad de agrupación inicial. Sin embargo, en un cluster ampliado, los servidores que residen de forma remota en la base de datos mostrarán una mayor latencia al iniciarse a medida que se utilice una mayor capacidad de agrupación inicial.
Se requiere una decisión equilibrada entre la optimización de los tiempos de respuesta durante el funcionamiento normal y la minimización de la hora de inicio para determinar la configuración de capacidad inicial ideal. Puesto que la capacidad inicial se configura en el nivel de origen de datos (pool de conexiones), estos valores influyen en el tiempo de inicio de todos los servidores del cluster (los locales de la base de datos y los que son remotos).
En el siguiente gráfico se muestran las horas de inicio del servidor WebLogic a medida que aumenta la latencia de la base de datos, para diferentes valores de tamaño inicial en todos los orígenes de datos (11 orígenes de datos en total):
Revisar tiempos de migración de servicio JMS
Sin embargo, el tiempo necesario para una operación de migración de servicio de la región 1 a la región 2 puede aumentar debido a la latencia de la base de datos. Este aumento se debe al tiempo dedicado a recuperar los mensajes en el otro servidor, ya que se leen desde el almacén persistente en la base de datos de la otra región.
El incremento es mayor si los almacenes persistentes tienen un gran número de mensajes pendientes. Para los mensajes JMS con un tamaño de 2,7 KB cada uno, la siguiente imagen muestra los tiempos de migración del servicio JMS cuando uno de los almacenes persistentes tiene un gran número de mensajes pendientes (alrededor de 8000) y el servicio migra de un servidor colocado con la base de datos a otro servidor, para diferentes latencias entre el servidor de destino y la base de datos:
En la siguiente imagen se muestra el incremento de tiempo de migración de servicio (%) con un gran número de mensajes pendientes (alrededor de 8000) para diferentes latencias entre el servidor de destino y la base de datos. La referencia (100 %) se produce cuando el servicio migra a un servidor que está en el mismo dominio de disponibilidad (AD) que la base de datos.
En la siguiente imagen se muestran los tiempos de migración para el mismo caso, pero con un número bajo de mensajes pendientes (alrededor de 50) para diferentes latencias entre el servidor de destino y la base de datos.
En la siguiente imagen se muestra el incremento de tiempo de migración del servicio JMS (%) con un número bajo de mensajes pendientes (alrededor de 50) para diferentes latencias entre el servidor de destino y la base de datos. La referencia (100%) es cuando el servicio migra a un servidor que está en el mismo dominio de disponibilidad que la base de datos.
Revisión de Tiempos de Despliegue de Compuesto de SOA
Al desplegar un compuesto (desplegar su primera versión o actualizarlo a una versión más reciente), el compuesto se puede desplegar antes en los servidores de la región 1 que en los servidores de la región 2, aunque no se activará formalmente hasta que esté disponible en todos los miembros del cluster.
En la siguiente imagen se muestra el aumento del tiempo que se tarda en cargar un compuesto en un servidor durante el inicio del servidor, con latencia en la base de datos en comparación con el tiempo que se tarda en cargarlo en un servidor que reside en el mismo dominio de disponibilidad (AD) que la base de datos. El tamaño compuesto es de 365 KB.
En la siguiente imagen se muestra el aumento del tiempo que se tarda en desplegar un compuesto con los comandos de Oracle WebLogic Scripting Tool (WLST), para diferentes latencias del servidor que realiza el despliegue en la base de datos.
Revisar tráfico entre sitios
Sin embargo, este aislamiento no es determinista (por ejemplo, hay espacio para escenarios de failover en los que se podría realizar una llamada a Java Message Service (JMS) en los dos sitios). Dicho esto, para una aplicación típica, la mayor parte del tráfico se produce entre las instancias de Oracle WebLogic Server y la base de datos. Esta será la clave para el rendimiento de la topología de clusters ampliados de Oracle Fusion Middleware (FMW). En esta imagen se muestra el porcentaje de tráfico entre un servidor WebLogic en la región 2 y las diferentes direcciones en la región 1 durante una prueba de esfuerzo. Observe que más del 90% del tráfico se produce entre el servidor y la base de datos, que se encuentra en la región 1.
Para capturar la cantidad de tráfico por IP entre los sitios, puede utilizar la herramienta iftop. Por ejemplo:
sudo iftop -i ens3 -F <remote_site_CIDR> -n -t -s 900En la siguiente imagen se muestra el porcentaje de tráfico entre un servidor WebLogic en la región 2 y las diferentes direcciones en la región 1 durante una prueba de esfuerzo.
