¿Recibe a menudo quejas de los clientes sobre la baja velocidad de respuesta de las páginas JSP? ¿Alguna vez ha pensado en cómo su aplicación WEB puede soportar el creciente número de visitas cuando el número de visitas de clientes aumenta drásticamente? Este artículo describe algunos métodos muy prácticos para ajustar JSP y servlets, que pueden hacer que sus páginas de servlet y JSP sean más responsivas y escalables. Además, a medida que aumenta el número de usuarios, la carga del sistema mostrará una suave tendencia ascendente. En este artículo, utilizaré algunos ejemplos prácticos y métodos de configuración para mejorar inesperadamente el rendimiento de su aplicación. Algunas de estas técnicas de ajuste se implementan en su trabajo de programación. Otras tecnologías están relacionadas con la configuración del servidor de aplicaciones. En este artículo, describiremos en detalle cómo mejorar el rendimiento general de su aplicación ajustando servlets y páginas JSP. Antes de leer este artículo, se supone que tiene conocimientos básicos de servlets y JSP.
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 pueda seguir utilizándose durante la siguiente llamada SQL:
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");
}
captura (NamingException ne)
{
ne.printStackTrace();
}
captura (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 el servlet y la página JSP sin tener que reiniciar la aplicación. servidor. 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. Puedes mejorar el rendimiento del sistema manejando HttpSession de las siguientes maneras:
· Si no es necesario, debes desactivar la configuración predeterminada para HttpSession en la página JSP: Si no lo especificas explícitamente, cada página JSP se creará de forma predeterminada para crear una HttpSession. . Si no necesita utilizar la sesión en su JSP, puede desactivarla a través del siguiente indicador de página JSP:
<%@ page session="false"%>
· No almacene objetos de datos grandes en HttpSession: si tiene datos grandes El objeto se almacena en HttpSession, el servidor de aplicaciones lo 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 necesites la sesión HttpSession, libérala lo antes posible: cuando ya no necesites la sesión, puedes 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 para la implementación de este método:
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 ("comprimir")! = -1)
{
request.setHeader("Codificación de contenido", "comprimir");
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 el indicador de inclusión (<%@ includee file="test.jsp" %>). 2. Utilice el indicador jsp (<jsp:includee page="test.jsp" flux="true"/>). En la práctica, descubrí que si 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. Al utilizar la etiqueta <jsp:useBean> en la página JSP, se pueden insertar javabeans directamente en una página JSP. Su uso es el siguiente:
<jsp:useBean id="nombre" alcance="página|request|session|application" class=
"paquete.nombredeclase" 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
: Intente no utilizar el operador "+" en operaciones de concatenación de cadenas: en la programación Java, a menudo utilizamos el operador "+" para conectar varias cadenas, pero es posible que nunca haya pensado en ello. En realidad, afectará al sistema. rendimiento, ¿verdad? Dado 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 "+".
· Evite el uso del 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 debemos intentar Evite usarlo llame. 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().
· Compensaciones entre ServletOutputStream y PrintWriter: El uso de PrintWriter puede generar una pequeña sobrecarga, porque convierte toda la salida sin procesar en un flujo de caracteres para la salida, por lo que si se usa como salida de página, el sistema tiene que 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. ¡Solo entonces podrás optimizar fundamentalmente tu aplicación!