限制对 servlet 的请求数量

发布于 2024-08-09 06:29:16 字数 195 浏览 6 评论 0原文

我们有一个 servlet,由于它所具有的逻辑,它在服务器上占用了更多的虚拟内存。因此,我们希望限制对此服务器的并发请求,例如我们只希望处理 10 个并发请求。其他请求必须在队列中等待。

是否可以创建一个自定义线程池并分配给该 servlet 来处理这种情况?我们使用的是 WebLogic 服务器 9.2。或者还有其他更好的方法来做到这一点吗?欣赏任何想法。

We have a servlet which occupies more virtual memory on the server due to the logic it has. For this reason, we would like to limit the concurrent requests to this server say for example we would only want 10 concurrent requests processed. The other requests have to wait in the queue.

Can a custom thread pool be created and assign for this servlet to handle this scenario? We are using WebLogic server 9.2. Or is there any other better approach to do this? Appreciate any thoughts.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

好菇凉咱不稀罕他 2024-08-16 06:29:16

是否可以创建一个自定义线程池并分配给该 servlet 来处理这种情况?我们使用的是 WebLogic 服务器 9.2。或者还有其他更好的方法来做到这一点吗?感谢任何想法。

是的,这是可能的。而不是使用默认的自调整工作管理器(从 Weblogic 9.x 开始,执行队列被线程池的工作管理器取代1),您可以使用特定的 约束,例如 max-threads-constraint 和可能是容量。然后,您可以使用 wl-dispatch-policy


1 请注意,仍然可以 启用 WebLogic 8.1 线程池模型并使用执行队列。

Can a custom thread pool be created and assign for this servlet to handle this scenario? We are using WebLogic server 9.2. Or is there any other better approach to do this? Appreciate any thoughts.

Yes, this is possible. Instead of using the default self-tuning work manager (starting with Weblogic 9.x, execute queues are replaced by work managers for thread pools1), you could create a work manager with specific constraints like the max-threads-constraint and possibly the capacity. You can then assign a Servlet to a specific work manager using the wl-dispatch-policy of the weblogic.xml deployment descriptor file.


1 Note that it's still possible to enable WebLogic 8.1 Thread Pool Model and to use Execute Queues.

贱贱哒 2024-08-16 06:29:16

您需要在前面或托管 servlet 的计算机上进行一些操作,因为当请求到达计算机时,有点太晚了:资源已被使用。您无法控制需求方:您只能对其做出反应并制定计划。

根据您的目标要求,您可能需要软件或硬件负载平衡器。软件负载平衡器可以简单地是具有会话控制的“调度程序servlet”(例如10个并发到servlet X)。

还有另一种可能性:您通过发出适当的 HTTP 代码来“限制”请求者。当然,这意味着请求方需要额外的逻辑......并且它仍然消耗服务器端的一些资源。

You need something in front or the machine hosting the servlet because when the requests hit the machine, it is somewhat too late: resources are already being used. You can't control the demand side: you can only react to it and plan for it.

You need probably a load-balancer either software or hardware depending on your target requirements. The software load-balancer can be simply a "dispatcher servlet" with session control (e.g. 10 concurrent to servlet X).

There is another possibility: you "throttle" the requesters by issuing an appropriate HTTP code. Of course, this means additional logic on the requester side... and it still consumes some resources on the server side.

饮湿 2024-08-16 06:29:16

您可以进行负载平衡,以便有一个辅助服务器来处理昂贵的 servlet 的所有请求。

You could load-balance such that there's a secondary server that processes all requests for the expensive servlet.

不爱素颜 2024-08-16 06:29:16

您可以有一个静态计数器和一个仅充当昂贵方法调用网关的 servlet。您只需要处理这个静态计数器上可能的竞争条件。

因此,您可以将当前的 servlet 转换为方法调用。

然后,网关 servlet 将获取请求,查看计数器是否足够低,然后递增。如果超过10,则返回一些错误消息。

这不是理想的情况,但如果您将内容放入队列中,那么浏览器将在一段时间后开始超时,或者用户会变得不耐烦并一遍又一遍地单击提交按钮,因为它花费的时间太长。

如果您可以使用 javascript 发送请求,那么有一些更好的解决方案可以帮助您。

You could have a static counter, and a servlet that just acts as a gateway to the expensive method call. You just need to deal with a probably race condition on this static counter.

So, you would turn your current servlet into a method call.

Then, the gateway servlet will get the request, see if the counter is low enough and then increment. If over 10, then return some error message.

This is not an ideal situation but if you put things into a queue then browsers will begin to timeout after a while, or users get impatient and click the submit button over and over, as it is taking too long.

If you could use javascript to send the request then there are some better solutions that may help you.

诗笺 2024-08-16 06:29:16

在不使用负载均衡器等的情况下,在我看来,您希望将请求与处理分离。

例如

  1. 浏览器发送一个请求。 servlet 接收它,将其排队并返还一张票。
  2. servlet 将在资源允许的情况下处理此工作请求(使用单独的线程池从队列中提取工作项)。
  3. 浏览器可以使用该票证刷新(重新获取),并且servlet 将返回适当的结果(例如,未处理、正在处理、已处理)。

这是一种很常见的模式。请注意,浏览器不会被阻止,而只是分派请求,然后定期执行检查以查看工作项是否完成。我已经成功地使用了这个(例如)在用户请求需要 5 分钟或更长时间来处理的图表并且使用非线程安全的本机库的情况下。在这种情况下,我必须将处理限制为单个线程,无论同时请求的数量如何。

Without using load-balancers etc., it seems to me that you want to decouple the request from the processing.

e.g.

  1. the browser sends a request. The servlet takes it, queues it and hands back a ticket.
  2. The servlet will work on this work request as resources permit (using a separate thread pool pulling the work items from the queue).
  3. The browser can refresh (re-GET) using that ticket, and the servlet will return an appropriate result (e.g. not processing, processing, processed).

This is quite a common pattern. Note that the browser isn't blocked, but merely dispatches the request and then regularly performs checks to see if the work item is complete. I've used this successfully (for example) in the situation where I've had users asking for charts that take 5 mins or more to process, and that used a native library that wasn't thread-safe. In that scenario I had to restrict the processing to a single thread regardless of the number of simultaneous requests.

一袭白衣梦中忆 2024-08-16 06:29:16

我喜欢使用静态计数器并在计数器超出限制时重定向以显示错误消息的想法。

我们可以配置一个单独的 servlet 并将线程池配置为仅允许 X 个并发请求,所有其他请求将被放入队列中以使用下一个可用的 servlet。这种方法会引发超时错误吗?您能否分享更多细节?谢谢

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

I like the idea of using static counter and redirecting to show an error message when the counter has reached beyond a limit.

Could we configure a separate servlet and configure the thread pool to only allow X number of concurrent requests, all other requests would be placed in queue to use the next available servlet. Does this approach throw a timeout error? Can you please share more details around this? Thanks

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文