问题描述
我有一个 Web 应用程序，它充当运行很长时间任务的异地服务器的接口.用户输入信息并点击提交，然后 chrome 等待响应，并在收到响应时加载一个新网页.然而，根据网络和用户的输入，该任务可能需要相当长的时间，有时 chrome 会在返回数据之前加载无数据接收页面"(尽管任务仍在运行).
I have a web application which acts as an interface to an offsite server which runs a very long task. The user enters information and hits submit and then chrome waits for the response, and loads a new webpage when it receives it. However depending on the network, input of the user, the task can take a pretty long time and occasionally chrome loads a "no data received page" before the data is returned (though the task is still running).
有没有办法在我的任务正在思考时放置一个临时页面，或者只是强制 chrome 继续等待?提前致谢
Is there a way to put either a temporary page while my task is thinking or simply force chrome to continue waiting? Thanks in advance
推荐答案
虽然您可以更改服务器上的超时或其他技巧以尝试保持页面活动"，但请记住可能还有其他部分您无法控制的可能使请求超时的连接(例如浏览器的超时值，或浏览器和服务器之间的任何代理等).此外，如果任务需要更长时间才能完成(变得更高级，或者只是因为更多人使用它而变慢)，您可能需要不断提高超时值.
While you could change your timeout on the server or other tricks to try to keep the page "alive", keep in mind that there might be other parts of the connection that you have no control over that could timeout the request (such as the timeout value of the browser, or any proxy between the browser and server, etc). Also, you might need to constantly up your timeout value if the task takes longer to complete (becomes more advanced, or just slower because more people use it).
最终，这类问题通常可以通过更改架构来解决.
In the end, this sort of problem is typically solved by a change in your architecture.
不是在处理视图中提交请求并运行任务，而是视图在单独的进程中启动任务的运行，然后立即返回响应.此响应可以将用户带到请稍候，我们正在处理"页面.该页面可以使用众多推送技术中的一种来确定任务何时完成(长轮询、网络套接字、服务器发送的事件、每 N 秒一次的 AJAX 请求，或者最简单的:让页面重新加载每 5 秒一次).
Rather than submitting the request and running the task in the handling view, the view starts the running of the task in a separate process, then immediately returns a response. This response can bring the user to a "Please wait, we're processing" page. That page can use one of the many push technologies out there to determine when the task was completed (long-polling, web-sockets, server-sent events, an AJAX request every N seconds, or the dead-simplest: have the page reload every 5 seconds).
无论如何，正如我所说，处理请求的视图不会执行长时间操作:它只是启动后台进程来为其执行任务.你可以自己创建这个后台进程调度(查看 这个 Flask 代码段想法)，或者使用像 Celery 或 (RQ).
Anyway, as I said, the view handling the request doesn't do the long action: it just kicks off a background process to do the task for it. You can create this background process dispatch yourself (check out this Flask snippet for possible ideas), or use a library like Celery or (RQ).
任务完成后，您需要通过某种方式通知用户.这将取决于您在上面选择的通知方法类型.对于一个简单的每 N 秒的 ajax 请求"，您需要创建一个视图来处理检查任务是否完成的 AJAX 请求.执行此操作的典型方法是让长时间运行的任务作为最后一步对数据库进行一些更新.检查状态的请求然后可以检查这部分数据库是否有更新.
Once the task is complete, you need some way of notifying the user. This will be dependent on what sort of notification method you picked above. For a simple "ajax request every N seconds", you need to create a view that handles the AJAX request that checks if the task is complete. A typical way to do this is to have the long-running task, as a last step, make some update to a database. The requests for checking the status can then check this part of the database for updates.
使用这种方法(而不是尝试将长时间运行的任务放入请求中)有几个好处:
Using this method (rather than trying to fit the long-running task into a request) has a few benefits:
1.) 处理长时间运行的 Web 请求是一项棘手的工作，因为有多个点可能超时(除了浏览器和服务器之外).使用这种方法，您的所有网络请求都非常短，而且超时的可能性也大大降低.
1.) Handling long-running web requests is a tricky business due to the fact that there are multiple points that could time out (besides the browser and server). With this method, all your web requests are very short and much less likely to timeout.
2.) Flask(以及其他类似的框架)旨在仅支持一定数量的线程来响应 Web 查询.假设它有 8 个线程:如果其中四个正在处理长请求，那么只剩下四个请求来实际处理更典型的请求(例如用户获取他们的个人资料页面).您的 Web 服务器的一半可能会被捆绑做一些不提供 Web 内容的事情！更糟糕的是，您可以让所有八个线程都运行一个很长的进程，这意味着您的网站在其中一个完成之前完全无法响应网络请求.
2.) Flask (and other frameworks like it) is designed to only support a certain number of threads that can respond to web queries. Assume it has 8 threads: if four of them are handling the long requests, that only leaves four requests to actually handle more typical requests (like a user getting their profile page). Half of your web server could be tied up doing something that is not serving web content! At worse, you could have all eight threads running a long process, meaning your site is completely unable to respond to web requests until one of them finishes.
主要缺点:在启动和运行任务队列时需要做更多的设置工作，而且它确实使您的整个系统稍微复杂一些.但是，对于在网络上运行的长时间运行的任务，我强烈推荐这种策略.
The main drawback: there is a little more set up work in getting a task queue up and running, and it does make your entire system slightly more complex. However, I would highly recommend this strategy for long-running tasks that run on the web.
这篇关于铬和烧瓶的超时问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2