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 próxima llamada SQL:
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";
}
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, a saber, la tecnología de recarga automática, que proporciona a los desarrolladores un buen entorno de desarrollo sin tener que reiniciar el servidor de aplicaciones cuando cambia el servlet y las páginas JSP. 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 abuses 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 manejando HttpSession de las siguientes maneras:
Si no es necesario, debe desactivar la configuración predeterminada de HttpSession en la página JSP: si no lo especifica explícitamente, cada página JSP creará una HttpSession de forma predeterminada. Si no necesita utilizar la sesión en su JSP, puede desactivarla mediante el siguiente indicador de página JSP:
＜%@ 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
La compresión es una buena forma 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. Aquí hay un fragmento de código de cómo se implementa 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 ("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áginas adecuado
Hay dos formas de incluir otra página en JSP: 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
Una de las características poderosas 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. Aquí se explica cómo usarlo:
＜jsp:useBean id="name" alcance="página|request|session|application" class=
"package.className" type="typeName"＞
＜/jsp:useBean＞
El atributo de alcance indica 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.
otros métodos
Trate de no utilizar el operador "+" en las operaciones de concatenación de cadenas: en la programación Java, a menudo usamos el operador "+" para conectar varias cadenas, pero es posible que nunca haya pensado que realmente afectaría el rendimiento del sistema. 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 evitarlo. usándolo. Pero es una herramienta indispensable y conveniente cuando depuramos el programa. Para resolver esta contradicción, le sugiero que utilice la herramienta Log4j, que puede facilitar la depuración sin generar el método System.out.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 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.
Resumir
El propósito de este artículo es mejorar enormemente el rendimiento de su aplicación mediante algunas técnicas de ajuste de servlets y JSP, y así 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!