这个网络应用程序需要任务队列吗？
背景
我有一个网络应用程序，它将根据用户输入创建图像。 图像创建可能需要几秒钟的时间。
问题
如果我让服务器线程处理请求/响应也生成图像，这将占用线程几秒钟，并可能使我的服务器陷入困境，影响性能，杀死小狗等。
问题
< strong>我是否应该使用任务队列，例如Celery，以便服务器可以交接图像创建，以及返回处理请求/响应？ 我可以让创建图像的用户等待，但我不希望它影响其他人对网站的访问。
Background
I have a web app that will create an image from user input.
The image creation could take up to a couple seconds.
Problem
If I let the server thread, that is handling the request/response also generate the image, that is going to tie up a thread for a couple seconds, and possibly bog down my server, affect performance, kill puppies, etc.
Question
Should I use a task queue, such as Celery, so that the server can hand off the image creation, and go back to handling requests/responses? I have no problem letting the user who is creating the image wait, but I dont want it to effect other peoples access to the site.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我现在要说“不”。
因此，一开始就保持简单并使其正常工作，但请记住，您稍后可能会添加任务队列。
当/如果您需要扩展时，请实现该任务队列。
I'm going to say No - for now.
So, keep it simple at first and get it working, but Keep in mind that you might add a task queue later.
Implement that task queue when/if you need to scale.
我也有一个图像生成网站（Names4Frames），并通过 AJAX（和 PHP）执行类似的操作。我没有遇到任何明显的速度下降（或死狗），但相关网站也没有产生大量流量。我不是线程方面的专家，说实话，我不能 100% 确定您确切关心的是什么以及您正在使用什么技术...
基本上有一个页面从另一个页面请求图像（甚至可能位于不同的服务器），完成后第二页会将有关图像的任何相关信息传回第一页以进行处理/显示目的。如果我们只谈论几秒钟，我看不出这是一个真正的问题，除非您要处理大量不断使用此图像创建服务的访问者。
I have an image-generating site as well (Names4Frames) and did things like this via AJAX (and PHP). I haven't had any noticeable slow-downs (or dead puppies), but the site in question doesn't generate huge amounts of traffic either. I am not an expert on threads, and to be honest, I'm not 100% sure what your exact concern is and what technologies you're using...
Basically have one page request the image from another page (Perhaps even located on a different server), and when it's done the second page passes back to the first any relevant information about the image for processing/display purposes. If we're only talking about a few seconds, I can't see that being a real problem, unless you're dealing with MASSIVE amounts of visitors constantly using this image creation service.
经验法则：如果任务可能堆积，请使用队列。
在您的情况下，该任务可能需要最多 2 秒，假设每天 8 小时，您每天最多可以处理 8*60*60/2 = 14400 张图像（无需并发）。如果您每天收到超过 7200 个请求，则其中任何一个请求重叠的可能性为 50%。有更复杂的分析可以显示您可能获得的预期重叠程度；但可以肯定地说，在超负荷之前，您每天可以拍摄一千多张图像。
现在问题似乎更容易了：您认为很快您每天会创作出超过一千或两个图像吗？如果有，则设置队列；如果没有，请稍后再处理。
无论如何，保留良好的日志；确保您可以判断何时存在任何处理重叠。请记住，一旦您同时处理两个任务，它们将花费更长的时间，从而增加了在完成另外两个任务之前完成第三个任务的可能性，以及第四个……当您到达一个看不见的阈值时，性能将急剧下降。不要为此失眠，只是不要让它在你注意到之前发生。
rule of thumb: use a queue if tasks could pile up.
In your case, the task could take up to 2 seconds, assuming 8hours a day, you could do up to 8*60*60/2 = 14400 images a day without concurrency. If you get over 7200 requests a day, you have a 50% chance of any one of them overlapping. There are more sophisticated analysis to show the expected level of overlapping you're likely to get; but it seems safe to say that you could do over a thousand images a day before getting overloaded.
Now the question seems easier: Do you think you'll get more than a thousand or two image creations a day anytime soon? If so, then set a queue; if not, leave it for later.
In any case, keep good logs; make sure that you could tell when there's any processing overlap. Remember that once you get two tasks processing concurrently, they'll take longer, increasing probabilities that a third one could arrive before finishing the other two, and a fourth... when you arrive to an invisible threshold, performance will plummet drastically. Don't lose sleep on this, just don't let it happen before you notice.