用铬和烧瓶超时问题 [英] Time out issues with chrome and flask
问题描述
有没有办法在我的任务正在思考时放置一个临时页面，或者只是强制使用chrome继续等待？在此先感谢
虽然您可以更改服务器上的超时或其他技巧以尽量保持页面活跃请记住，连接的其他部分可能无法控制超时请求（例如浏览器的超时值或浏览器和服务器之间的任何代理等）。另外，如果任务需要更长的时间才能完成，则可能需要不断提高超时值（变得更高级，或者更慢，因为更多的人使用它）。
在最后，这类问题通常是通过改变你的体系结构来解决的。
为长时间运行的任务使用单独的过程
视图不是在处理视图中提交请求并运行任务，而是在单独的进程中启动任务运行，然后立即返回响应。这个响应可以把用户带到请稍候，我们正在处理页面。该页面可以使用其中的一种推送技术来确定任务何时完成（长轮询，web-sockets，服务器发送的事件，每N秒一个AJAX请求，或者最简单的方法：让页面重新加载每5秒钟）。
有你的Web请求踢开分开的过程
无论如何，说，处理请求的视图不会执行长时间的操作：它只是启动后台进程来完成任务。你可以自己创建这个后台进程调度（查看这个Flask代码片段想法），或使用像芹菜或（ RQ ）。
一旦任务完成，您需要一些通知用户的方法。这将取决于您在上面选择的通知方式。对于每N秒一个简单的ajax请求，您需要创建一个处理AJAX请求的视图来检查任务是否完成。一个典型的方法是做长期的任务，作为最后一步，对数据库进行一些更新。然后检查状态的请求可以检查数据库的这部分更新。
优点和缺点
使用这种方法（而不是试图将长时间运行的任务合并到请求中）有一些好处：处理长时间运行的web请求是一个棘手的问题。因为有多个点可能超时（除了浏览器和服务器）。使用这种方法，所有的web请求都很短，而且不太可能超时。
2。）Flask（和其他类似的框架）被设计为只支持一定数量的线程可以响应网页查询。假设它有8个线程：如果其中四个正在处理长请求，那么只留下四个请求来实际处理更多的典型请求（如用户获取其个人资料页面）。你的网络服务器的一半可能被捆绑做一些不提供网络内容的东西！更糟糕的是，所有八个线程都会运行一个漫长的过程，这意味着您的站点完全无法响应Web请求，直到其中一个完成。
主要缺点：在建立和运行任务队列方面还有一些工作要做，而且这会使整个系统稍微复杂一点。不过，我强烈建议这个策略适用于网络上长时间运行的任务。
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).
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.
Use a Separate Process for Long-Running Tasks
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).
Have your Web Request "Kick Off" the Separate Process
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).
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.
Advantages and Disadvantages
Using this method (rather than trying to fit the long-running task into a request) has a few benefits:
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 (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.
这篇关于用铬和烧瓶超时问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
