Desempeño de terracota y consejos

Question

Acabo de aprender a usar Terracotta después de descubrirlo hace aproximadamente un mes. Es una tecnología muy buena.

Básicamente lo que estoy tratando de hacer:

Mi raíz (Sistema de registro) es un ConcurrentHashMap.

La clase instrumentada principal es un "JavaBean" con 30 o más campos que deseo que existan en HashMap.

Habrá aproximadamente 20000 de estos JavaBeans que existen en el Hashmap.

Cada bean tiene (al menos) 5 campos que se actualizarán cada 5 segundos.

(La razón por la que estoy usando terracota de esto es porque estas JavaBeans tienen que ser accesibles a través de JVM y nodos.)

Cualquier persona con más experiencia que yo con TC tienen algún consejo? El rendimiento es clave.

¿Ejemplos de otras aplicaciones similares?

Answer 1

puede encontrarse con que varios lotes cambios menores de un alcance de bloqueo se obtienen mejores resultados. Cada bloque/método sincronizado forma una transacción de escritura (suponiendo que utilice un bloqueo de escritura) que debe enviarse al servidor (y posiblemente volver a salir a otros nodos). Al cambiar un grupo de campos, posiblemente en un grupo de objetos bajo un bloqueo, se reduce la sobrecarga de crear una transacción. Algo para jugar al menos.

El particionamiento también es una forma clave de mejorar el rendimiento. Solo se deben enviar cambios a los nodos que realmente están usando un objeto. Por lo tanto, si puede particionar qué nodos generalmente tocan objetos específicos que reducen el número de cambios que se deben enviar alrededor del clúster, lo que mejora el rendimiento.

Las sugerencias de unnutz sobre el uso de CHM o CSM son buenas. CHM permite una mayor concurrencia (ya que cada segmento interno se puede bloquear y usar al mismo tiempo); asegúrese de experimentar con recuentos de segmento más grandes también. CSM tiene efectivamente un bloqueo por entrada, por lo que tiene particiones N efectivamente en una tabla de tamaño N. Eso puede reducir enormemente la contención de bloqueo (a costa de administrar más objetos de bloqueo interno). Los cambios que se avecinan pronto para CSM harán que el bloqueo mgmt cueste mucho menos.

En general nos encontramos con una buena estrategia es:

1. Construir una prueba de rendimiento (debe ser multi-hilo y multi-nodo y similar a su aplicación (o su aplicación real!)
2. Sintonice objetos: observe el gráfico de objetos agrupados en la consola de desarrollo para encontrar objetos que no necesitan agruparse en absoluto; a veces, esto sucede accidentalmente (elimine o corte el clúster con un campo transitorio). A veces puede estar agrupando una Fecha en la que haría un largo. Pequeño cambio, pero ese es un objeto por entrada de mapa y eso podría marcar la diferencia.
3. Sintonizar bloqueos: use el perfil de bloqueo en la consola dev para encontrar bloqueos o bloqueos demasiado angostos o demasiado anchos. El registrador de estadísticas agrupadas también puede ayudar a observar el tamaño de las transacciones.
4. Sintonice GC y DGC - sintonice la recolección de basura JVM, luego sintonice el GC distribuido por Terracotta activando el cambio de la frecuencia de young gen gc.
5. Sintonice el servidor TC - muchas afinaciones muy detalladas para hacer aquí, pero por lo general no valen la pena hasta que las cosas anteriores estén sintonizadas.

No dude en preguntar en el Terracotta forums también - todos los de ingeniería, ingeniería de campo, producto mgmt ver esos y responder allí.

Answer 2

En primer lugar, le sugiero que plantee esta pregunta en sus foros también.

En segundo lugar, en realidad, el rendimiento de su aplicación agrupada en Terracotta dependerá de la cantidad de transacciones de escritura que sucedan. Por lo tanto, podría considerar usar ConcurrentStringMap (si sus claves son Strings) o ConcurrentHashMap. Tenga en cuenta que CSM es mucho mejor que CHM desde el punto de rendimiento.

Después de todo, los POJO se cargan perezosamente. Eso significa que cada propiedad se carga a pedido.

Espero que ayude.

Saludos