No usar mapeo para servlets en JBoss y Mejorar Rendimiento JBoss

Tomado de:

No usar mapeo para servlets en JBoss

   Si no desea mapear cada servlet en web.xml del JBoss y desea llamarlos directamente incluyendo el paquete y el nombre del Servlet, entonces agregue lo siguiente en el archivo web.xml de la aplicacion.

.......
    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
   </servlet>
 
   <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
   </servlet-mapping>
...... 

Mejorar rendimiento Jboss
Tomado de:
Tunning Jboss

Al final encontré en un foro que se trata de o bien modificar el fichero de configuración de JBoss ..\deploy\jbossweb.sar.context.xml añadiendo las propiedades reloadable="false" privileged="true"
También existe la posibilidad de crearte un context.xml en la aplicación que vayas a desplegar y así no tocas el de configuración del JBoss. De porque este cambio no lo sé ya que son mis primeros inicios en JBoss y he encontrado esto en un foro en internet.

Ahora que en el nuevo lugar de trabajo lidiamos a diario con servidores de aplicación JBoss, veamos algunos trucos para optimizar su funcionamiento.
El más importante de todos y en el que hicieron mucho hicapié es en el hot deploy. Para entornos de producción no se recomienda tenerlo activado, aunque si no queremos desprendernos de esta utilidad, siempre podemos prolongar su tiempo de chequeo. Veamos como hacerlo:
Editando el archivo de configuración jboss-service.xml ubicado en el directorio conf de nuestra configuración, tenemos que modificar:
<!-- A flag to disable the scans -->
<attribute name="ScanEnabled">true</attribute>
Cambiando a false ala variable, los despliegues en caliente se deshabilitarán.
Si por el contrario, decidimos ampliar los tiempos de búsqueda para nuevos despliegues, editaremos la siguiente entrada:
<!-- Frequency in milliseconds to rescan the URLs for changes -->
<attribute name="ScanPeriod">5000</attribute>
Podríamos ponerlo cada hora (3600000), no olvidemos que estos tiempos se miden en milisegundos.

JBoss es un servidor de aplicaciones que se ejecuta sobre la JVM, así que deberemos afinar y mejorar todo lo posible el rendimiento de esta, para que las aplicaciones que despleguemos sobre JBoss se ejecuten con la máxima eficiencia. Si esto lo sumamos a un buen diseño de las aplicaciones y una arquitectura adecuada (sin sobredimensionarla), obtendremos un resultado óptimo (tened en cuenta que siempre falla uno de los 3).
Es fundamental aplicar estas buenas prácticas no solo a JBoss, sino a servidores que trabajan sobre la JVM.
1.-Xms y Xmx
Asignar el mismo valor a cada uno de estos parámetros optimiza el trabajo dentro de la memoria, porque es donde se reserva la memoria que se va a usar, estando toda seguida y no espaciada por toda la memoria, cosa que dilataría la recuperación de información.
2.- GC
Este posiblemente sea uno de los aspectos más importantes a la hora de hacer más eficiente nuestro servidor de aplicaciones.
Lo que haremos será usar el sistema de recolección distribuido.
-Dsun.rmi.dgc.client.gcInterval=1800000
-Dsun.rmi.dgc.server.gcInterval=1800000
Por defecto el tiempo de acción es muy reducido, cada minuto, por lo que normalmente todos suelen establecerlo a 3600000 (una hora), en entornos de producción. En mi opinión esto no mejora mucho el rendimiento porque es dilatar demasiado esta acción, por ello debemos hacer que se ejecute ajustándolo a nuestras necesidades, el tiempo que mejor resultado me ha ofrecido es de 30 minutos.
No olvidemos que esta acción, penaliza mucho mientras se está ejecutando, porque está organizando gran parte de la memoria.
3.- Ejecución paralela
Podemos hacer que se ejecuten varios hilos del GC, consiguiendo que la cantidad de elementos organizados y eliminados sea mayor. -XX:+ UseParallelGC
Esto ejecutará tantos hilos como procesadores tenga nuestra máquina, quizás queramos que solo se encarguen 2 procesadores de esta tarea, así que podemos establecer el número máximo de hilos con el parámetro: -XX:ParallelGCThreads=2
4.- 70%
La memoria Heap no debe superar el 70% de la memoria física, para evitar errores de paginación y que la recolección de basura sea más eficiente.