playframework - starter - ¿Qué sucede cuando se cambia de DEV a modo PROD en el archivo "application.conf"?

play framework starter (3)

Estoy usando play framework 1.2.5, durante los últimos dos días tuve un problema muy grande en la prueba de carga que es para cada llamada API al servidor que toma alrededor de 1200-1400ms como promedio, pero hoy solo cambié la siguiente sola línea en el archivo application.conf que reduce drásticamente el tiempo promedio a 20 - 50 ms , la línea de la siguiente manera,

application.mode=prod %prod.application.mode=prod

inicialmente fue como

application.mode=dev %prod.application.mode=prod

Así que de esto pude entender que cambiar de dev a producción hace algo y lo que encontré en Internet es, en el modo dev play.pool = 1 por defecto, mientras que en el modo de producción play.pool = no de procesadores + 1 , mi máquina ubuntu es 4 procesadores por lo que usa 5 hilos. Ahora, llegando al problema, si lo que encontré es verdadero, entonces cuando cambio el play.pool = 5 manualmente en la aplicación.conf no me da un resultado más rápido ni si configuro play.pool = 1 y me ejecuto en modo de producción también no ralentiza los resultados de la prueba de carga de mi aplicación, así que necesito saber qué sucede cuando cambie de dev a modo prod, que no sea este play.pool, lo que hace que mi aplicación sea más rápida. porque estoy enfrentando un problema en UAT donde no hay buenos resultados para cambiar también en el modo prod, solo funciona en mi servidor local. Por favor, encuéntrame una solución antes gracias en Advance.

ACTUALIZAR:

Sí, conozco todos estos productos, como en modo DEV, la aplicación se recarga y compila, pero tal vez no sea para todas y cada una de las solicitudes solo en el programa inicial de carga, creo, pero mi problema es que este modo prod funciona bien en mi servidor local y mi local. servidor, cuando voy por UAT obtengo malos resultados en la prueba de carga de 800ms como promedio. la aplicación es lenta incluso en prod, incluso estoy realizando la prueba de carga localmente (el jmeter está instalado en la máquina del servidor y estoy probando la carga mediante Conexión a Escritorio remoto). Entonces, aparte de la compilación y recarga, necesito saber cuáles son todos los cambios realizados en el archivo application.conf cuando cambio de DEV a modo PROD, como el play.pool cambia de 1 thread a (no de procesadores + 1) thread. FYI: mi sistema localhost es una máquina de 4 procesadores, y la máquina servidor local es de 4 procesadores, pero la máquina UAT es de 2 procesadores, si este es el problema, incluso intenté cambiar los hilos de la agrupación a 10 (play.pool = 10) y no buenos resultados en UAT.

Además del único hilo, en el modo dev el inicio de la aplicación se retrasa hasta que se envía la primera solicitud. En el modo prod , la aplicación comenzará de inmediato. Esto obviamente afecta el tiempo de carga de la primera solicitud.

Supongo que el rendimiento "malo" en el modo dev es principalmente causado por la función de volver a cargar y compilar clases mientras se ejecuta. En cada solicitud, las clases se verifican para ver si hay cambios y se pueden volver a cargar. Creo que esta característica vale mucho más los tiempos de carga y no sé si es posible desactivarla.

Probablemente no deberías ejecutar ninguna prueba de rendimiento / aceptación en el modo dev. Aquí hay una breve discusión al respecto . En lugar de tratar de aumentar el rendimiento del modo dev, solo debe usar el modo prod.

¿Cómo estás jugando en el servidor de producción?

Espero que haya leído: http://www.playframework.com/documentation/1.2.5/production

Su pregunta es realmente sobre un problema de rendimiento. Puede haber muchas cosas que causan una diferencia de rendimiento de su entorno y producción local. Aparte de Play, ¿está corriendo el DB en la misma caja?

Deberías hacer un análisis más antes de saltar a tus armas.
En primer lugar, intenta comprender dónde se gasta ese tiempo extra.

¿Prestando las plantillas?
¿Está esperando Hanging DB Connections?
¿Hay algún bloqueo de hilo?
¿Se ha optimizado la base de datos con índices?
¿Has medido el uso del procesador y la memoria?
¿Estás haciendo operaciones costosas de IO?
¿Hay algún otro proceso ejecutándose en esta máquina?