plan - Java Performance Testing

jmeter test web

Question

Esta pregunta ya tiene una respuesta aquí:

• ¿Es aceptable la evaluación comparativa del cronómetro? 13 respuestas

Quiero hacer algunas pruebas de tiempo en una aplicación Java. Esto es lo que estoy haciendo actualmente:

long startTime = System.currentTimeMillis();
doSomething();
long finishTime = System.currentTimeMillis();
System.out.println("That took: " + (finishTime - startTime) + " ms");

¿Hay algo "incorrecto" en las pruebas de rendimiento como este? ¿Cuál es una mejor manera?

Duplicado : ¿Es aceptable el benchmarking de cronómetro?

Answer 1

¿Has mirado las herramientas de creación de perfiles en netbeans y eclipse ? Estas herramientas le dan un mejor manejo de lo que REALMENTE está ocupando todo el tiempo en su código. He encontrado problemas de los que no me había dado cuenta al usar estas herramientas.

Answer 2

Bueno, eso es solo una parte de las pruebas de rendimiento. Dependiendo de lo que está probando, es posible que tenga que ver el tamaño del montón, el conteo de subprocesos, el tráfico de la red o una gran cantidad de otras cosas. De lo contrario, uso esa técnica para cosas simples que solo quiero ver cuánto tardan en ejecutarse.

Answer 3

El código que se muestra en la pregunta no es un buen código de medición del rendimiento:

1. El compilador puede elegir optimizar su código reordenando las declaraciones. Sí, puede hacer eso. Eso significa que toda su prueba puede fallar. Incluso puede elegir alinear el método bajo prueba y reordenar las declaraciones de medición en el código ahora en línea.

2. El punto de acceso puede elegir reordenar sus declaraciones, código en línea, resultados de caché, demora en la ejecución ...

3. Incluso suponiendo que el compilador / punto de acceso no te engañó, lo que mides es "tiempo de pared". Lo que debe medir es el tiempo de CPU (a menos que use recursos del sistema operativo y desee incluirlos también o mida la impugnación de bloqueo en un entorno de subprocesos múltiples).

¿La solución? Use un generador de perfiles real. Hay muchos, tanto perfiladores libres como demostraciones / ensayos con bloqueo de tiempo de comerciales.

Answer 4

Eso es bueno cuando comparas una implementación con otra o tratas de encontrar una parte lenta en tu código (aunque puede ser tedioso). Es una técnica realmente buena para saber y probablemente la usarás más que cualquier otra, pero también estarás familiarizado con una herramienta de creación de perfiles.

Answer 5

Tenga en cuenta que la resolución de System.currentTimeMillis() varía según los diferentes sistemas operativos. Creo que Windows es alrededor de 15 mseg. Entonces, si su doSomething() ejecuta más rápido que la resolución de tiempo, obtendrá un delta de 0. Puede ejecutar doSomething() en un bucle varias veces, pero entonces la JVM puede optimizarlo.

Answer 6

El uso de un Analizador de Java es la mejor opción y le dará toda la información que necesita sobre el código. viz Response Times, Thread CallTraces, Utilizaciones de memoria, etc.

Sugeriré que JENSOR , un Analizador Java de código abierto, sea fácil de usar y no tenga gastos generales en la CPU. Puede descargarlo, instrumentar el código y obtener toda la información que necesita sobre su código.

Puede descargarlo de: http://jensor.sourceforge.net/

Answer 7

Me imagino que querrías hacer algo () antes de comenzar a cronometrar, para que el código esté JITted y "calentado".

Answer 8

Japex puede ser útil para usted, ya sea como una forma de crear rápidamente puntos de referencia, o como una forma de estudiar problemas de evaluación comparativa en Java a través del código fuente.

Answer 9

El único defecto en ese enfoque es que el tiempo "real" que doSomething() tarda en ejecutarse puede variar mucho dependiendo de qué otros programas se estén ejecutando en el sistema y cuál es su carga. Esto hace que la medición del rendimiento sea algo impreciso.

Una forma más precisa de rastrear el tiempo que se tarda en ejecutar el código, suponiendo que el código es de un solo hilo, es observar el tiempo de CPU consumido por el hilo durante la llamada. Puedes hacer esto con las clases JMX; en particular, con ThreadMXBean . Puede recuperar una instancia de ThreadMXBean desde java.lang.management.ManagementFactory y, si su plataforma lo admite (la mayoría lo hace), use el método getCurrentThreadCpuTime en lugar de System.currentTimeMillis para realizar una prueba similar. Tenga en cuenta que getCurrentThreadCpuTime informa el tiempo en nanosegundos, no en milisegundos.

Aquí hay un método de muestra (Scala) que podría usarse para realizar una medición:

def measureCpuTime(f: => Unit): java.time.Duration = {

  import java.lang.management.ManagementFactory.getThreadMXBean
  if (!getThreadMXBean.isThreadCpuTimeSupported)
    throw new UnsupportedOperationException(
      "JVM does not support measuring thread CPU-time")

  var finalCpuTime: Option[Long] = None
  val thread = new Thread {
    override def run(): Unit = {
      f
      finalCpuTime = Some(getThreadMXBean.getThreadCpuTime(
        Thread.currentThread.getId))
    }
  }
  thread.start()

  while (finalCpuTime.isEmpty && thread.isAlive) {
    Thread.sleep(100)
  }

  java.time.Duration.ofNanos(finalCpuTime.getOrElse {
    throw new Exception("Operation never returned, and the thread is dead " +
      "(perhaps an unhandled exception occurred)")
  })
}

(¡Siéntase libre de traducir lo anterior a Java!)

Esta estrategia no es perfecta, pero está menos sujeta a variaciones en la carga del sistema.