Limitar el número de solicitudes a un servlet

Question

Tenemos un servlet que ocupa más memoria virtual en el servidor debido a la lógica que tiene. Por esta razón, nos gustaría limitar las solicitudes simultáneas a este servidor, por ejemplo, solo queremos que se procesen 10 solicitudes simultáneas. Las otras solicitudes tienen que esperar en la cola.

¿Se puede crear un grupo de subprocesos personalizado y asignarlo a este servlet para manejar este escenario? Estamos utilizando el servidor WebLogic 9.2. ¿O hay algún otro enfoque mejor para hacer esto? Agradezco cualquier pensamiento.

Answer 1

  

¿Se puede crear un grupo de subprocesos personalizado y asignarlo a este servlet para manejar este escenario? Estamos utilizando el servidor WebLogic 9.2. ¿O hay algún otro enfoque mejor para hacer esto? Agradezco cualquier pensamiento.

Sí, esto es posible. En lugar de utilizar el administrador de trabajo de autoajuste predeterminado (comenzando con Weblogic 9.x, las colas de ejecución son reemplazadas por administradores de trabajo para grupos de subprocesos ¹ ), puede crear un administrador de trabajo con restricciones como max-threads-restriction y posiblemente la capacidad . Luego puede asignar un Servlet a un administrador de trabajo específico utilizando wl-dispatch-policy del archivo descriptor de implementación weblogic.xml .

---

¹ Tenga en cuenta que todavía es posible habilitar WebLogic 8.1 Thread Pool Model y usar Execute Queues.

Answer 2

Necesita algo al frente o la máquina que aloja el servlet porque cuando las solicitudes llegan a la máquina, es algo demasiado tarde: los recursos ya se están utilizando. no puede controlar la demanda : solo puede reaccionar ante ella y planificarla.

Probablemente necesite un equilibrador de carga, ya sea software o hardware, según sus requisitos de destino. El equilibrador de carga de software puede ser simplemente un "servlet despachador" con control de sesión (por ejemplo, 10 concurrentes al servlet X).

Hay otra posibilidad: usted "acelera" los solicitantes emitiendo un código HTTP apropiado. Por supuesto, esto significa lógica adicional en el lado del solicitante ... y aún consume algunos recursos en el lado del servidor.

Answer 3

Podría equilibrar la carga de modo que haya un servidor secundario que procese todas las solicitudes del costoso servlet.

Answer 4

Podría tener un contador estático y un servlet que simplemente actúa como una puerta de entrada a la costosa llamada al método. Solo necesita lidiar con una condición de carrera probable en este contador estático.

Entonces, convertiría su servlet actual en una llamada a método.

Luego, el servlet de la puerta de enlace recibirá la solicitud, verá si el contador es lo suficientemente bajo y luego incremente. Si tiene más de 10, devuelva algún mensaje de error.

Esta no es una situación ideal, pero si pones las cosas en una cola, los navegadores comenzarán a agotar el tiempo después de un tiempo, o los usuarios se impacientarán y harán clic en el botón Enviar una y otra vez, ya que está tardando demasiado.

Si pudieras usar javascript para enviar la solicitud, entonces hay algunas mejores soluciones que pueden ayudarte.

Answer 5

Sin utilizar equilibradores de carga, etc., me parece que desea desacoplar la solicitud del procesamiento.

p.

1. el navegador envía una solicitud. El servlet lo toma, lo pone en cola y le devuelve un boleto.
2. El servlet funcionará en esta solicitud de trabajo según lo permitan los recursos (utilizando un grupo de subprocesos separado que extraiga los elementos de trabajo de la cola).
3. El navegador puede actualizar (volver a OBTENER) usando ese ticket, y el servlet devolverá un resultado apropiado (por ejemplo, no procesando, procesando, procesado).

Este es un patrón bastante común. Tenga en cuenta que el navegador no está bloqueado, sino que simplemente envía la solicitud y luego realiza verificaciones regularmente para ver si el elemento de trabajo está completo. Lo he usado con éxito (por ejemplo) en la situación en la que los usuarios han pedido gráficos que tarden 5 minutos o más en procesarse, y que usaban una biblioteca nativa que no era segura para subprocesos. En ese escenario, tenía que restringir el procesamiento a un solo hilo, independientemente de la cantidad de solicitudes simultáneas.

Answer 6

Me gusta la idea de usar un contador estático y redirigir para mostrar un mensaje de error cuando el contador ha superado un límite.

¿Podríamos configurar un servlet separado y configurar el grupo de subprocesos para permitir solo X número de solicitudes simultáneas, todas las demás solicitudes se colocarían en la cola para usar el siguiente servlet disponible. ¿Este enfoque arroja un error de tiempo de espera? ¿Puedes por favor compartir más detalles sobre esto? Gracias

http://download.oracle.com /docs/cd/E13222_01/wls/docs92/perform/appb_queues.html