Método 1: almacenar en caché los datos en el método init() del servlet.
Después de que el servidor de aplicaciones inicializa la instancia del servlet y antes de atender las solicitudes del cliente, llama al método init() del servlet. En el ciclo de vida de un servlet, el método init() solo se llamará una vez. Al almacenar en caché algunos datos estáticos en el método init() o completar algunas operaciones que requieren mucho tiempo y que solo deben realizarse una vez, el rendimiento del sistema se puede mejorar considerablemente.
Por ejemplo, establecer un grupo de conexiones JDBC en el método init () es el mejor ejemplo. Supongamos que usamos la interfaz DataSource de jdbc2.0 para obtener una conexión de base de datos. En circunstancias normales, necesitamos obtener datos específicos a través de una fuente JNDI. Podemos imaginar que en una aplicación específica, si se ejecuta una consulta JNDI para cada solicitud SQL, el rendimiento del sistema disminuirá drásticamente. La solución es el siguiente código, que almacena en caché el origen de datos para que aún pueda usarse durante la siguiente llamada SQL:
El siguiente es un fragmento de referencia:
La clase pública ControllerServlet extiende HttpServlet {
prueba privada javax.sql.DataSourceDS = nulo;
public void init (configuración de ServletConfig) lanza ServletException {
super.init(config);
Contexto ctx = nulo;
intentar{
ctx = nuevoContextoInicial();
testDS = (javax.sql.DataSource)ctx.lookup("jdbc/testDS");
}catch(NamingException ne){ne.printStackTrace();}
}catch(Excepción e){e.printStackTrace();}
}
público javax.sql.DataSource getTestDS(){
prueba de retornoDS;
}
...
...
}
Método 2: deshabilitar la recarga automática de servlet y JSP (recarga automática)
Servlet/JSP proporciona una tecnología práctica, concretamente la tecnología de recarga automática, que proporciona a los desarrolladores un buen entorno de desarrollo cuando cambia las páginas de servlet y JSP sin tener que reiniciar el servidor de aplicaciones. Sin embargo, esta tecnología supone una gran pérdida de recursos del sistema durante la etapa de ejecución del producto, porque supondrá una gran carga para el cargador de clases del motor JSP. Por lo tanto, desactivar la función de recarga automática es de gran ayuda para mejorar el rendimiento del sistema.
Método 3: no abuse de HttpSession
En muchas aplicaciones, nuestro programa necesita mantener el estado del cliente para que las páginas puedan comunicarse entre sí. Pero desafortunadamente, debido a que HTTP es inherentemente sin estado, no puede guardar el estado del cliente. Por lo tanto, los servidores de aplicaciones generales proporcionan sesiones para guardar el estado del cliente. En el servidor de aplicaciones JSP, la función de sesión se implementa a través del objeto HttpSession, pero si bien es conveniente, también supone una gran carga para el sistema. Porque cada vez que obtiene o actualiza una sesión, el operador del sistema tiene que realizar en ella operaciones de serialización que requieren mucho tiempo. Puede mejorar el rendimiento del sistema mediante los siguientes métodos de procesamiento para HttpSession.
Si no es necesario, se deben desactivar las configuraciones predeterminadas para HttpSession en la página JSP. Cada página JSP creará una HttpSession de forma predeterminada si no la especifica explícitamente. Si no necesita utilizar la sesión en su JSP, puede desactivarla mediante el siguiente indicador de página JSP:
El siguiente es un fragmento de referencia:
＜%@ página sesión="false"%＞
No almacene objetos de datos grandes en HttpSession: si almacena objetos de datos grandes en HttpSession, el servidor de aplicaciones los serializará cada vez que se lea o escriba, lo que agregará una carga adicional al sistema. Cuanto mayor sea el objeto de datos que almacene en HttpSession, más rápido disminuirá el rendimiento del sistema.
Cuando ya no necesite HttpSession, libérela lo antes posible: cuando ya no necesite la sesión, puede liberarla llamando al método HttpSession.invalidate(). Intente establecer el tiempo de espera de la sesión lo más corto posible: en el servidor de aplicaciones JSP, hay un tiempo de espera de sesión predeterminado. Cuando el cliente no realice ninguna operación pasado este tiempo, el sistema liberará automáticamente de la memoria la sesión correspondiente. Cuanto mayor sea el tiempo de espera, menor será el rendimiento del sistema, por lo que la mejor manera es intentar mantener su valor lo más bajo posible.
Método 4: comprimir la salida de la página
es una buena manera de resolver la redundancia de datos, especialmente hoy en día cuando el ancho de banda de la red no está lo suficientemente desarrollado. Algunos navegadores admiten gzip (GNU zip) para comprimir archivos HTML. Este método puede reducir drásticamente el tiempo de descarga de archivos HTML. Por lo tanto, si comprime la página HTML generada por un servlet o una página JSP, el usuario sentirá que la velocidad de navegación de la página será muy rápida. Desafortunadamente, no todos los navegadores soportan la compresión gzip, pero puedes comprobar en tu programa si el navegador del cliente la soporta. El siguiente es un fragmento de código sobre la implementación de este método:
El siguiente es un fragmento de cita:
public void doGet (solicitud HttpServletRequest, respuesta HttpServletResponse)
lanza IOException, ServletException {
Salida de salida = nulo;
Codificación de cadena = request.getHeader("Aceptar-Codificación");
si (codificación! = nulo && codificación.indexOf("gzip")! = -1){
request.setHeader("Codificación de contenido", "gzip");
salida = nuevo GZIPOutputStream(request.getOutputStream());
}
de lo contrario si (codificación! = nulo && codificación.indexOf("comdivss")! = -1){
request.setHeader("Codificación de contenido", "comdivss");
salida = nuevo ZIPOutputStream(request.getOutputStream());
}demás{
salida = request.getOutputStream();
}
...
...
}
Método 5: utilice el grupo de subprocesos.
El servidor de aplicaciones crea un subproceso para procesar cada solicitud de cliente diferente de forma predeterminada y les asigna el método service(). Cuando se completa la llamada al método service(), el subproceso correspondiente también cancela. . Dado que la creación y destrucción de subprocesos consume ciertos recursos del sistema, este modo predeterminado reduce el rendimiento del sistema. Pero, afortunadamente, podemos cambiar esta situación creando un grupo de subprocesos.
Además, también debemos establecer una cantidad mínima de subprocesos y una cantidad máxima de subprocesos para este grupo de subprocesos. Cuando se inicia el servidor de aplicaciones, creará un grupo de subprocesos con un número igual al número mínimo de subprocesos. Cuando un cliente tiene una solicitud, se saca un subproceso del grupo para su procesamiento. Vuelva a colocarlo en el medio de la piscina. Si no hay suficientes subprocesos en el grupo, el sistema aumentará automáticamente la cantidad de subprocesos en el grupo, pero el número total no puede exceder el número máximo de subprocesos. Al utilizar el grupo de subprocesos, cuando las solicitudes de los clientes aumentan drásticamente, la carga del sistema mostrará una curva ascendente suave, mejorando así la escalabilidad del sistema.
Método 6: Elija el mecanismo de inclusión de página correcto.
Hay dos métodos en JSP que se pueden utilizar para incluir otra página:
1. Utilice la directiva de inclusión.
El siguiente es un fragmento de referencia:
＜%@ archivo incluido=”test.jsp” %＞
2. Utilice el indicador jsp.
El siguiente es un fragmento de referencia:
<jsp:includee page="test.jsp" flux="true"/>
En la práctica, se descubre que si se utiliza el primer método, el rendimiento del sistema puede ser mayor.
Método 7: determinar correctamente el ciclo de vida de javabeans
Uno de los aspectos poderosos de JSP es su soporte para javabeans. Los JavaBeans se pueden insertar directamente en una página JSP utilizando la etiqueta jsp:useBean en la página JSP. Aquí se explica cómo usarlo:
Aquí hay un fragmento de cita:
<jsp:useBean id="nombre" alcance="página|solicitud|sesión|aplicación"
clase="paquete.nombreclase" tipo="nombretipo">
＜/jsp:useBean＞
El atributo de alcance señala el ciclo de vida de este bean. El ciclo de vida predeterminado es página. Si no elige correctamente el ciclo de vida del bean, afectará el rendimiento del sistema.
Por ejemplo, si solo desea utilizar un determinado bean en una solicitud, pero establece el ciclo de vida del bean en sesión, cuando finalice la solicitud, el bean aún permanecerá en la memoria a menos que se agote el tiempo de espera de la sesión o el usuario cierre el navegador. Esto consumirá una cierta cantidad de memoria y aumentará innecesariamente la carga de trabajo del recolector de basura JVM. Por lo tanto, establecer el ciclo de vida correcto para los beans y limpiarlos lo antes posible una vez finalizada su misión mejorará el rendimiento del sistema.
Algunos otros métodos útiles
1. Intente no utilizar el operador "+" en las operaciones de conexión de cadenas: en la programación Java, a menudo usamos el operador "+" para conectar varias cadenas, pero es posible que nunca haya pensado en ello. ¿Rendimiento del sistema? Debido a que las cadenas son constantes, la JVM generará algunos objetos temporales. Cuanto más "+" utilice, más objetos temporales se generarán, lo que también tendrá algún impacto en el rendimiento del sistema. La solución es utilizar un objeto StringBuffer en lugar del operador "+".
2. Evite utilizar el método System.out.println(): dado que System.out.println() es una llamada sincrónica, es decir, al llamarla, la operación de E/S del disco debe esperar a que se complete, por lo que deberíamos intentarlo. para evitar su uso. Pero es una herramienta indispensable y conveniente cuando depuramos el programa. Para resolver esta contradicción, le sugiero que utilice la herramienta Log4j ( http://Jakarta.apache.org ), que puede facilitar la depuración sin métodos como System.out. Se generará .println().
3. Compensación entre ServletOutputStream y PrintWriter: el uso de PrintWriter puede generar una pequeña sobrecarga, porque convierte toda la salida original en un flujo de caracteres para la salida, por lo que si se usa como salida de página, el sistema debe soportar un proceso de conversión. No hay ningún problema si usa ServletOutputStream como salida de página, pero se genera en binario. Por lo tanto, se deben sopesar los pros y los contras de ambos en aplicaciones prácticas.
Resumen
El propósito de este artículo es mejorar en gran medida el rendimiento de su aplicación a través de algunas técnicas de ajuste para servlets y JSP y, por lo tanto, mejorar el rendimiento de toda la aplicación J2EE. A través de estas técnicas de ajuste, puede descubrir que no es una determinada plataforma técnica (como la disputa entre J2EE y .NET) la que determina el rendimiento de su aplicación. Lo importante es que tenga una comprensión más profunda de esta plataforma, por lo que. Sólo entonces podrás optimizar fundamentalmente tu aplicación.