Lo que está describiendo es 'Ajuste del rendimiento'. Cuando hablamos de ajuste de rendimiento hay dos ángulos. (a) Tiempo de respuesta: cuánto tiempo lleva ejecutar una solicitud/programa particular. (b) Rendimiento - Cuántas solicitudes puede ejecutar en un segundo. Cuando normalmente 'optimizamos' - cuando eliminamos el procesamiento innecesario, tanto el tiempo de respuesta como el rendimiento mejoran.Sin embargo, si tiene eventos de espera en su código (como Thread.sleep(), espera de E/S, etc.), su tiempo de respuesta se ve afectado, sin embargo, el rendimiento no se ve afectado. Al adoptar el procesamiento paralelo (engendrando múltiples hilos) podemos mejorar el tiempo de respuesta pero el rendimiento no mejorará. Normalmente, para la aplicación del lado del servidor, tanto el tiempo de respuesta como el rendimiento son importantes. Para aplicaciones de escritorio (como IDE) el rendimiento no es importante, solo el tiempo de respuesta es importante.
Puede medir el tiempo de respuesta mediante 'Prueba de rendimiento' - solo anota el tiempo de respuesta para todas las transacciones clave. Puede medir el rendimiento mediante 'Load Testing': necesita bombear solicitudes continuamente desde un número suficientemente grande de subprocesos/clientes, de forma que el uso de la CPU de la máquina del servidor sea del 80-90%. Cuando realizamos una solicitud de bomba, necesitamos mantener la relación entre diferentes transacciones (llamada mezcla de transacción), por ejemplo: en un sistema de reserva habrá 10 reservas por cada 100 búsquedas. habrá una cancelación por cada 10 reservas, etc.
Después de identificar las transacciones que requieren ajuste para el tiempo de respuesta (prueba de rendimiento), puede identificar los puntos calientes mediante el uso de un generador de perfiles. Puede identificar los puntos críticos para el rendimiento comparando el tiempo de respuesta * fracción de esa transacción. Supongamos que en el escenario de búsqueda, reserva, cancelación, la relación es 89: 10: 1. El tiempo de respuesta es 0.1 segundos, 10 segundos y 15 segundos. carga para la búsqueda - 0.1 * .89 = 0.089 carga para la reserva- 10 * .1 = 1 carga para cancell = 15 * .01 = 0.15 Aquí la reserva de sintonía tendrá un impacto máximo en el rendimiento. También puede identificar los puntos calientes para el rendimiento al tomar tiradas de subprocesos (en el caso de aplicaciones basadas en Java) repetidamente.
+1: Ese cronómetro es una pequeña utilidad práctica para controles rápidos, ¡gracias! –