descargar application java performance java-ee websphere

java - application - was 8 download



Servidor de aplicaciones Websphere: ¿qué diablos se necesita para comenzar rápido? (8)

Estoy usando Rational Application Developer v7.0 que se envía con un entorno de prueba integrado. Cuando llego a la depuración de mi aplicación web, el tiempo de inicio del servidor en el modo de depuración es de cerca de 5-6 minutos, ¡tiempo suficiente para tomar un café!

A veces, me molesta tanto que empiezo a maldecir a IBM por construir un sistema operativo en lugar de un servidor de aplicaciones. Engendrando más de 20 procesos y servicios inútiles sin configuración documentada para ajustarlo, para comenzar más rápido.

Estoy seguro de que hay muchos desarrolladores de Java que estarán de acuerdo conmigo en esto. Traté de desactivar las aplicaciones predeterminadas y un conjunto de servicios a través de mi consola de administración, sin embargo, eso no ha ayudado mucho.

No tengo servicios web, ni enterprise beans, ni colas, solo una aplicación web simple que requiere un grupo de conexiones. ¿Has hecho algo en el pasado para crear tu entorno de prueba integrado, comenzar rápido en modo de depuración y consumir menos RAM?

ACTUALIZACIÓN: Intenté desactivar algunos servicios (internacionalización, aplicaciones predeterminadas, etc.) y ahora el servidor de WebSphere fue de mal en peor. No solo no toma tiempo de arranque horrible, sino que se congela de vez en cuando durante hasta 2 minutos. :-( Parece que la optimización no es tan buena, ¡siempre!

5 a 6 minutos no es normal. Uso RAD y WAS todos los días y obtengo tiempos de arranque decentes. ¿Qué versión de WAS está ejecutando y cuánta RAM tiene?

Si comparte varios espacios de trabajo y proyectos para un mismo perfil de WAS, considere la posibilidad de crear un nuevo perfil de WAS para su espacio de trabajo.

Probablemente lo haya intentado, pero aquí hay una lista de verificación simple de cosas para probar de primera mano. Asegúrese de que la configuración de su servidor en RAD tenga las siguientes opciones habilitadas:

  • Optimizar el servidor para probar y desarrollar
  • Ejecutar servidor con recursos en el área de trabajo
  • Minimice los archivos de la aplicación copiados en el servidor

Desmarque "Habilitar cliente de prueba universal" si no lo necesita.

En la consola de administración puede verificar algunas configuraciones de servidor como

  • Ejecutar en modo de desarrollo
  • Paralelo de inicio
  • Comience los componentes según sea necesario

También puede desinstalar la aplicación ivt que viene instalada de forma predeterminada al crear un nuevo perfil WAS. Luego, las cosas habituales, como una unidad que no está demasiado fragmentada y un tamaño de archivo de página que está configurado correctamente.

Y una última cosa que probablemente ya sepa, republique a su servidor en lugar de reiniciarlo.

Esa es una de las razones por las cuales nació Spring.

Ni siquiera tiene que dar todas las sutilezas como JMS, comunicación remota, etc. Sería mejor con Tomcat, ActiveMQ y OpenEJB.

Cualquier cosa menos WebSphere.

Hay algunos consejos y sugerencias para ajustar RAD 6 en developerworks que pueden ser de ayuda, muchos de estos también se aplican para RAD 7.

He visto una lista similar para RAD 7, la publicaré si puedo encontrarla.

Encontré algunos consejos de ajuste para Portal en RAD 7 .

Diría que mi experiencia con el entorno de prueba ha sido subóptima. Ahora tiendo a utilizar Tomcat / Pluto configurado para la depuración remota con una configuración de ejecución externa para administrarlo desde Eclipse simple y confiar en tener configuraciones JNDI apropiadas para abstraer el servidor subyacente.

Si está codificando las API relevantes, no debería importar para fines de desarrollo que no esté en Websphere. Si tienes un problema específico de Webpshere, siempre puedes subir la bestia para depurarla.

La mejor forma de depurar el código del servidor es usar la depuración remota.

Primero, debe agregar lo siguiente a los parámetros de JVM en el script de inicio del servidor:

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

Esto causará que la JVM escuche en el puerto especificado, luego desde su IDE puede iniciar una sesión de depuración remota contra ese puerto y depurar como si el código se ejecutara en el mismo proceso.

Trabajar de esta forma evita que reinicie el servidor con tanta frecuencia y, por lo tanto, minimiza su problema con el tiempo de inicio de Websphere.

Puedes obtener resultados extraños si los binarios en el servidor y la fuente en el IDE se desincronizan, pero en general eso no es un problema.

Si el grupo de conexiones realmente es la única característica del servidor de aplicaciones que utiliza, ¿por qué no utiliza apache commons dbcp ( http://commons.apache.org/dbcp/ ) y suelta webfear junto con embarcadero? Eso debería reducir su tiempo de inicio a aproximadamente 5 segundos. Posteriormente, puede cambiar fácilmente a la esfera web nuevamente para su entorno de producción si realmente siente la necesidad de hacerlo.

Si no tiene EJBs, no JMS, etc., simplemente implemente en un contenedor de servlets independiente como Tomcat o Jetty, se sorprenderá de lo rápido que es :-), siendo irónico aquí, ¡pero es verdad!

Una de las razones principales es que tiene una aplicación grande con muchos módulos, clases, manifiestos, descriptores XML, etc., y el hecho de que el proceso de inicio del servidor de aplicaciones Websphere es de un solo hilo per se (por lo tanto, cada aplicación puede iniciarse de forma separada hilo si tienen el mismo peso). Otra razón es que los marcos Eclipse EMF y JST son muy intensivos en I / O durante el inicio y la publicación / implementación.

Otra razón del tedioso inicio es el escaneo de anotaciones que ocurrirá durante la publicación / implementación. Este escaneo de anotación se puede controlar y modificar de varias maneras. Mira este sitio: http://wasdynacache.blogspot.se/2012/05/how-to-speed-up-annotation-processing.html

En primer lugar, examine y evalúe su hardware, tanto CPU, memoria y disco duro. ¿Sus procesadores están funcionando al 100% durante un tiempo prolongado durante el inicio? Si es así, el procesador puede ser demasiado débil. ¿Hay paginación? entonces puede que tenga que poner más RAM. Los frameworks JST y EMF de Websphere / eclipse son muy intensos en E / S, por lo que debería considerar invertir en un disco SSD. También debe asegurarse de que otros procesos en su máquina (software de protección antivirus, etc.) no roben los recursos de hardware de los procesos java Websphere.

Entonces para el hardware: 1. Procesador - uno bastante rápido, ya que la publicación y el inicio son en su mayoría singlethreaded, no necesitas tantos CPUs 2. Memoria - Al menos necesitarás 512Mb de RAM física, esto depende del tamaño de su aplicación, por supuesto. 3. Almacenamiento: Definitivamente iría por un SSD rápido ya que el marco de eclipse subyacente es intensivo de E / S.

Aquí hay algunos trucos para reducir la huella de la fase de inicio. Antes de aplicar estos ajustes, asegúrese de registrar un inicio de línea base para que pueda observar la diferencia en el inicio, es decir, el tiempo de inicio reducido.

  1. JVM args: -Xverify: none -Xquickstart -Xnoclassgc -XX: + UseNUMA -XtlhPrefetch -Xgcthreads4 (Tengo 4 procesadores virtuales instalados en mi máquina)
  2. Extienda el tamaño del montón para que coincida con las demandas de su aplicación.
  3. Inhabilite el inicio automático de la aplicación para reducir el tiempo de publicación.
  4. Deshabilite el PMI y el seguimiento innecesario.
  5. Perfile su aplicación durante el inicio y solucione los cuellos de botella si la encuentra.

Otros argumentos de JVM que pueden obtener rendimiento:

  • com.ibm.cacheLocalHost = true
  • com.ibm.ws.classloader.zipFileCacheSize = 512
  • com.ibm.ws.classloader.resourceRequestCacheSize = 1024
  • com.ibm.ws.management.event.pull_notification_timeout = 20000
  • com.ibm.ws.amm.scan.context.filter.packages = true
  • org.eclipse.jst.j2ee.commonarchivecore.disableZip = true

Los argumentos de Jvm que harán que el servidor de aplicaciones de Websphere se detenga inmediatamente:

  • com.ibm.ejs.sm.server.quiesceTimeout = 0
  • com.ibm.ejs.sm.server.quiesceInactiveRequestTime = 1000

Propiedades del contenedor web:

  • com.ibm.wsspi.jsp.disableTldSearch = true
  • com.ibm.wsspi.jsp.disableResourceInjection = true

Argumentos JVM que pueden especificarse eclipse.ini (Tenga en cuenta que los parámetros del montón están configurados según las condiciones de mi entorno)

  • -Dcom.ibm.ws.management.event.max_polling_interval = 5000
  • -Xquickstart
  • -Xverify: ninguno
  • -Xmxcl25000
  • -Xjit: dataTotal = 65536
  • -Xcodecache64m
  • -Xscmx48m
  • -Nuevos números
  • -Xverify: ninguno
  • -Xmnx64m
  • -Xmx1446m
  • -Xmnx64m
  • -XX: + UseCompressedOops
  • -XX: + UsarNUMA

WAS V7 soluciona algunos de estos problemas al permitirle configurar lo que se inicia cuando se inicia el servidor de la aplicación.

Por lo tanto, si migra a WAS V7 y cuándo lo hace, es posible que le parezcan algunas mejoras en este espacio.