2010-04-04 17 views
29

Me gustaría crear una lista de comprobación exhaustiva para la aplicación Java de baja latencia. ¿Puedes agregar tu lista de verificación aquí?¿Cuál es su lista de comprobación de desarrollo para la aplicación Java de baja latencia?

Aquí está mi lista
1. Haga sus objetos inmutables
2. Trate de reducir el método sincronizado
orden 3. Bloqueo debe estar bien documentado, y manejarla con cuidado
4. Uso de perfiles
5 . Utilice la ley de Amdhal, y encontrar la ruta de ejecución secuencial
6. uso de Java 5 Utilidades de concurrencia, y cerraduras prioridades de los hilos
7. Evita, ya que son dependientes de la plataforma
calentamiento 8. JVM puede ser utilizado
9. Prefiero estrategia de bloqueo injusto
10. Evitar el contexto de conmutación (muchos hilos conducen a contrarrestar productiva)
11. Evitar el boxeo, el boxeo no-
12. Prestar atención a las advertencias del compilador
13. Número de hilos debe ser igual o menor que el número del núcleo

La aplicación de baja latencia se sintoniza cada milisegundos.

+2

Mucha gente escribe aplicaciones Java de baja latencia que responden en mucho menos de 1 ms. Para mí, la baja latencia en Java significa menos de milisegundos. –

+0

Gracias, he cambiado. –

+0

* "6. Use locks" * => o incluso mejor, intente liberar el algoritmo. – assylias

Respuesta

0

Use StringBuilder en lugar de String al generar cadenas grandes. Por ejemplo, consultas.

+2

solo tiene sentido cuando quiere hacer algo con la Cadena, p. concatenar otras cadenas o revertir o tal. – Tedil

+1

Por lo general, no hace diferencia. ¡Los códigos de bytes que genera el compilador Java para las concatenaciones de cadenas usan StringBuilders! –

+0

La concatenación en un bucle (o enunciados múltiples) es el caso habitual en el que gana explícitamente 'StringBuilder'. –

6

Aunque la inmutabilidad es buena, no necesariamente va a mejorar la latencia. Garantizar baja latencia es probable que dependa de la plataforma.

Aparte del rendimiento general, la sintonización de GC es muy importante. La reducción del uso de memoria ayudará a GC. En particular, si puede reducir el número de objetos de mediana edad que necesitan moverse, manténgalo bien de larga vida o de corta duración. También evite cualquier cosa que toque el gen de la permanente.

+0

Hawtin, ¿no usar estructuras de datos inmutables ayuda a la latencia cuando no tiene que sincronizarse con datos compartidos? –

+0

esta es probablemente la mejor respuesta aquí – bestsss

5

evitar el boxeo/desempaquetado, utilice variables primitivas si es posible.

+0

Punto valioso. –

0

Otra idea importante es hacerlo funcionar primero, luego medir el rendimiento, luego aislar los cuellos de botella, luego optimizarlos, luego medir nuevamente para verificar la mejora.

Como dijo Knuth, "la optimización prematura es la raíz de todo mal".

+1

Pocos del éxito o el fracaso de la aplicación solo dependen del rendimiento. Aunque la optimización prematura es incorrecta, esa regla no se adapta a todas las aplicaciones. La aplicación de baja latencia debe ser construida con ciertas pautas. –

+1

Siempre me gustó "Haz que funcione primero, antes de hacerlo funcionar rápido". – Oversteer

+1

Me gustaría tener en cuenta que, una vez dicho esto, Knuth dedicó la mayor parte de su vida a la eficiencia algorítmica. :) –

4

Evitar el cambio de contexto siempre que sea posible en el camino de procesamiento de mensajes Consecuencia: utilizar NIO e hilo de bucle único evento (reactor)

+0

Gracias, se agrega su punto valioso. –

1

no programar más hilos en la aplicación de lo que tiene núcleos en el hardware subyacente. Tenga en cuenta que el sistema operativo requerirá la ejecución de subprocesos y posiblemente otros servicios que compartan el mismo hardware, por lo que se le puede solicitar a su aplicación que use menos del número máximo de núcleos disponibles.

+1

Esto es cierto para las tareas de cálculo intensivo, no necesariamente para las tareas de bloqueo/IO/otras donde tiene sentido tener más hilos. Si tiene más hilos y núcleos, tendrá que "arreglárselas" de modo que los cálculos intensivos se fijen por separado de los bloqueantes. –

2

Mida, mida y mida. Utilice datos tan cercanos a los reales con un hardware de producción tan cercano para ejecutar puntos de referencia de manera regular. Las aplicaciones de baja latencia a menudo se consideran mejor como dispositivos, por lo que debe tener en cuenta el cuadro completo implementado, no solo el método/clase/paquete/aplicación/JVM en particular, etc.Si no construyes puntos de referencia realistas en la producción como configuración, tendrás sorpresas en la producción.

4

Evite el bloqueo exhaustivo y el multi-threading para no interrumpir las funciones mejoradas en los procesadores modernos (y sus cachés). Luego puede usar un solo subproceso hasta sus límites increíbles (6 millones de transacciones por segundo) con muy baja latencia.

Si usted quiere ver un mundo real aplicación Java de baja latencia con suficientes detalles acerca de su arquitectura echar un vistazo a LMAX:

The LMAX Architecture

0

creo "utilizar objetos mutables única en su caso" es mejor que "Haz que tus objetos sean inmutables". Muchas aplicaciones de latencia muy baja tienen grupos de objetos que reutilizan para minimizar GC. Los objetos inmutables no se pueden reutilizar de esa manera. Por ejemplo, si usted tiene una clase Ubicación:

class Location { 
    double lat; 
    double lon; 
} 

Puede crear alguna en el arranque y utilizarlos una y otra vez para que nunca se hacen las asignaciones y la posterior GC.

Este enfoque es mucho más complicado que usar un objeto de ubicación inmutable, por lo que solo se debe usar donde sea necesario.

0

Además de las soluciones de nivel desarrollador descritas aquí, también puede ser muy beneficioso considerar tiempos de ejecución acelerados de JIT, por ejemplo, soluciones de memoria Zing y Off Heap como Teracotta BigMemory, Apache Ignite para reducir las pausas del mundo Stop-the-GC. Si alguna GUI involucró el uso de protocolos binarios como Hessian, ZERO-C ICE en lugar de webservice, etc. es muy efectivo.

Cuestiones relacionadas