5

Tengo dos preguntas. La primera es hacer Los filtros agregan una gran cantidad de sobrecarga para solicitar. Tenemos un filtro y está configurado para ejecutarse en el patrón de URL/*. Esto significa que también se ejecuta en todas las solicitudes de imágenes. Creo que esto no es bueno para el rendimiento, pero mis compañeros de trabajo piensan que no importa si el filtro se ejecuta 5 o 6 veces por solicitud porque el filtro solo tiene un par de declaraciones if.Pregunta de rendimiento de filtros de Java

Hay una manera de hacer que el filtro se ejecute una vez por solicitud, ignorando la solicitud de imagen.

Gracias Doug

+0

Comprueba si la contraseña de un usuario ha expirado. Obtiene esta información de la sesión – Doug

+0

Por definición, los filtros solo se ejecutan una o dos veces por solicitud. Potencialmente antes y después del servlet en el que están sentados. Las imágenes se sirven en respuesta a una solicitud por separado del cliente. –

+0

@Ian: su '' se puede configurar para ejecutarse en cada 'PETICIÓN' y/o 'ADELANTE' y/o 'INCLUDE'. Por defecto es 'SOLICITUD'. – BalusC

Respuesta

0

Casi nunca es útil especular sobre las implicaciones de rendimiento del código sin primero perfilarlo. A menos que el código que se propone en los filtros esté haciendo algunas operaciones que usted sabe que son lentas, mida primero antes de optimizar.

Recuerde a pesar de que cuando se escribe un servlet puede parecer que la única cosa que sucede es el código en sus doGet() o doPost() métodos un montón de otras cosas que pasan antes de su código de servlet/filtro se invoca. El contenedor de servlet procesa la solicitud HTTP, lo agrupa en objetos Java y realiza todo tipo de otros procesos antes de transferirlos a su código.

Si sus filtros servlet son realmente solo un par de declaraciones if que operan con datos que son baratos (como la propia solicitud), es poco probable que esto sea un problema para usted.

4

Medir es saber. Si está bien escrito, diría que es insignificante. Pero si, por ejemplo, captura la sesión independientemente de que se haya creado (y existe la posibilidad de que se cree innecesariamente), puede tener un impacto notable en el rendimiento y/o en el uso de la memoria porque la creación de sesiones no se realiza es barato y las sesiones se almacenan en la memoria de sever por un plazo más largo que las solicitudes.

Es posible que desee reemplazar el url-pattern de /* por *.jsp o mover las páginas restringidas a una carpeta específica, p. /secured, /private, /pages, etc. y modifique el url-pattern según /secured/*, /private/*, /pages/*, etc. y coloque todo el contenido estático en un lugar diferente, p. Ej. /static. De esta forma, el filtro ya no se invocará para contenido estático.

+1

Estoy de acuerdo con la medición. Estamos caminando muy cerca de la optimización prematura con esta pregunta. –

1

Primero, estoy de acuerdo con el enfoque de Perfil primero.

En segundo lugar, hasta donde yo sé que depende, el servidor web usa la misma técnica para invocar un servidor específico (/ JSP) que utilizan para los filtros.

En caso de que el filtro está filtrando un recurso estático (por ejemplo, archivo jpg), que es un poco de una pérdida, En caso de que el filtro está filtrando un recurso dinámico (por ejemplo Servlet) es insignificante .. (La mayor parte del Java los frameworks web como struts y Jboss-seam usan filtros en gran medida.)