Environment:
- Windows Server 2003 - IIS 6.x
- ASP.NET 3.5 (C#)
- IE 7,8,9
- FF (whatever the latest 10 versions are)
Windows Server 2003 - IIS 6.x.
ASP.NET 3.5(C#)
FF(无论最新的10个版本是什么)
User Scenario:
User enters search criteria against large data-set. After initiating the request, they are navigated to a results page, where they wait until the data is loaded and can then refine the data.
用户输入针对大型数据集的搜索条件。在启动请求后,它们将导航到结果页面,在那里它们等待数据加载,然后可以优化数据。
Technical Scenario:
After user sends search criteria (via ajax call), UI calls back-end service. Back-end service queries transactional system(s) and puts the resulting data into a db "cache" - a denormalized table, set-up for further refining the of the data (i.e. sorting, filtering). UI waits until the data is cached and then upon getting notified that the process is done, navigates to a resulting page. The resulting page then makes a call to get the data from the denormalized table.
用户发送搜索条件后(通过ajax调用),UI调用后端服务。后端服务查询事务系统并将结果数据放入db“缓存” - 非规范化表,设置用于进一步细化数据(即排序,过滤)。 UI等待数据被缓存,然后在收到通知已完成的过程后,导航到生成的页面。然后,生成的页面调用以从非规范化表中获取数据。
Problem:
The search is relatively slow (15-25 seconds) for large queries that end up having to query many systems based on the criteria entered. It is relatively fast for other queries ( <4 seconds).
对于大型查询,搜索相对较慢(15-25秒),最终必须根据输入的条件查询许多系统。其他查询(<4秒)相对较快。
Technical Constraints:
-
We can not entirely re-architect this search / results system. There are way to many complexities here between how the UI and the back-end is tied together. The page is required (because of constraints that can not be solved on *) to turn after performing the search criteria.
我们无法完全重新构建此搜索/结果系统。 UI和后端如何捆绑在一起,有很多复杂的方法。执行搜索条件后,页面是必需的(因为在*上无法解决的约束)。
-
We also can not ask the organization to denormalize the data prior to searching because the data has to be real-time, i.e. if a user makes a change in other systems, the data has to show up correctly if they do a search afterwards.
我们也不能要求组织在搜索之前对数据进行非规范化,因为数据必须是实时的,即如果用户在其他系统中进行了更改,则数据必须在之后进行搜索时正确显示。
Process that I want to follow:
我想要遵循的流程:
-
I want to cheat a little. I want to issue the "Cache" request via an async HttpHandler in a fire-forget model.
我想欺骗一点。我想在fire-forget模型中通过异步HttpHandler发出“Cache”请求。
-
After issuing the query, I want to transition the page to the resulting page.
发出查询后,我想将页面转换为结果页面。
-
On the transition page, I want to poll the "Cache" table to see if the data has been inserted into it yet.
在转换页面上,我想轮询“缓存”表以查看数据是否已插入其中。
-
The reason I want to do this transition right away, is that the resulting page is expensive on itself (even without getting the data) - still 2 seconds of load time before even getting to calling the service that gets the data from the cache.
我想立即进行这种转换的原因是结果页面本身很昂贵(即使没有获取数据) - 甚至在调用从缓存中获取数据的服务之前仍然需要2秒的加载时间。
Question:
Will the ASP.NET thread that is called via the async handler reliably continue processing even if I navigate away from the page using a javascript redirect?
即使我使用javascript重定向离开页面,通过异步处理程序调用的ASP.NET线程是否可靠地继续处理?
Technical Boundaries 2:
技术边界2:
Yes, I know... This search process does not sound efficient. There is nothing I can do about that right now. I am trying to do whatever I can to get it to perform a little better while we continue researching how we are going to re-architect it.
是的,我知道......这个搜索过程效率不高。我现在无能为力。在我们继续研究如何重新构建它的同时,我正在尽我所能让它更好地发挥作用。
If your answer is to: "Throw it away and start over", please do not answer. That is not acceptable.
如果您的答案是:“扔掉并重新开始”,请不要回答。这是不可接受的。
3 个解决方案
#1
4
Yes.
There is the property Response.IsClientConnected which is used to know if a long running process is still connected. The reason for this property is a processes will continue running even if the client becomes disconnected and must be manually detected via the property and manually shut down if a premature disconnect occurs. It is not by default to discontinue a running process on client disconnect.
有一个属性Response.IsClientConnected,用于知道长时间运行的进程是否仍然连接。此属性的原因是,即使客户端断开连接,进程也将继续运行,必须通过属性手动检测,如果发生过早断开,则手动关闭。默认情况下,不会在客户端断开连接上中断正在运行的进程。
Reference to this property: http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
参考此属性:http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
update
FYI this is a very bad property to rely on these days with sockets. I strongly encourage you to do an approach which allows you to quickly complete a request that notes in some database or queue of some long running task to complete, probably use RabbitMQ or something like that, that in turns uses socket.io or similar to update the web page or app once completed.
仅供参考,这是一个非常糟糕的财产,依赖于这些天的插座。我强烈建议你做一个方法,它允许你快速完成一个请求,在一些数据库或一些长时间运行的任务的队列中完成注释,可能使用RabbitMQ或类似的东西,反过来使用socket.io或类似的更新网页或应用程序一旦完成。
#2
3
How about don't do the async operation on an ASP.NET thread at all? Let the ASP.NET code call a service to queue the data search, then return to the browser with a token from the service, where it will then redirect to the result page that awaits the completed result? The result page will poll using the token from the service.
如何不在ASP.NET线程上进行异步操作呢?让ASP.NET代码调用服务来排队数据搜索,然后使用服务中的令牌返回浏览器,然后它将重定向到等待完成结果的结果页面?结果页面将使用服务中的令牌进行轮询。
That way, you won't have to worry about whether or not ASP.NET will somehow learn that the browser has moved to a different page.
这样,您就不必担心ASP.NET是否会以某种方式了解浏览器已移至其他页面。
#3
0
Another option is to use Threading (System.Threading).
When the user sends the search criteria, the server begins processing the page request, creates a new Thread responsible for executing the search, and finishes the response getting back to the browser and redirecting to the results page while the thread continues to execute on the server background.
The results page would keep verifying on the server if the query execution had finished as the started Thread would share the progress information. When it does finish, the results are returned when the next ajax call is done by the results page.
另一种选择是使用线程(System.Threading)。当用户发送搜索条件时,服务器开始处理页面请求,创建一个负责执行搜索的新线程,并完成响应返回浏览器并重定向到结果页面,同时线程继续在服务器上执行背景。如果查询执行已完成,结果页面将继续在服务器上进行验证,因为启动的线程将共享进度信息。完成后,结果页面完成下一个ajax调用时会返回结果。
It could also be considered using WebSockets. In a sense that the Webserver itself could tell the browser when it is done processing the query execution as it offers full-duplex communications channels.
也可以考虑使用WebSockets。从某种意义上说,Web服务器本身可以告诉浏览器何时完成处理查询执行,因为它提供了全双工通信通道。
#1
4
Yes.
There is the property Response.IsClientConnected which is used to know if a long running process is still connected. The reason for this property is a processes will continue running even if the client becomes disconnected and must be manually detected via the property and manually shut down if a premature disconnect occurs. It is not by default to discontinue a running process on client disconnect.
有一个属性Response.IsClientConnected,用于知道长时间运行的进程是否仍然连接。此属性的原因是,即使客户端断开连接,进程也将继续运行,必须通过属性手动检测,如果发生过早断开,则手动关闭。默认情况下,不会在客户端断开连接上中断正在运行的进程。
Reference to this property: http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
参考此属性:http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
update
FYI this is a very bad property to rely on these days with sockets. I strongly encourage you to do an approach which allows you to quickly complete a request that notes in some database or queue of some long running task to complete, probably use RabbitMQ or something like that, that in turns uses socket.io or similar to update the web page or app once completed.
仅供参考,这是一个非常糟糕的财产,依赖于这些天的插座。我强烈建议你做一个方法,它允许你快速完成一个请求,在一些数据库或一些长时间运行的任务的队列中完成注释,可能使用RabbitMQ或类似的东西,反过来使用socket.io或类似的更新网页或应用程序一旦完成。
#2
3
How about don't do the async operation on an ASP.NET thread at all? Let the ASP.NET code call a service to queue the data search, then return to the browser with a token from the service, where it will then redirect to the result page that awaits the completed result? The result page will poll using the token from the service.
如何不在ASP.NET线程上进行异步操作呢?让ASP.NET代码调用服务来排队数据搜索,然后使用服务中的令牌返回浏览器,然后它将重定向到等待完成结果的结果页面?结果页面将使用服务中的令牌进行轮询。
That way, you won't have to worry about whether or not ASP.NET will somehow learn that the browser has moved to a different page.
这样,您就不必担心ASP.NET是否会以某种方式了解浏览器已移至其他页面。
#3
0
Another option is to use Threading (System.Threading).
When the user sends the search criteria, the server begins processing the page request, creates a new Thread responsible for executing the search, and finishes the response getting back to the browser and redirecting to the results page while the thread continues to execute on the server background.
The results page would keep verifying on the server if the query execution had finished as the started Thread would share the progress information. When it does finish, the results are returned when the next ajax call is done by the results page.
另一种选择是使用线程(System.Threading)。当用户发送搜索条件时,服务器开始处理页面请求,创建一个负责执行搜索的新线程,并完成响应返回浏览器并重定向到结果页面,同时线程继续在服务器上执行背景。如果查询执行已完成,结果页面将继续在服务器上进行验证,因为启动的线程将共享进度信息。完成后,结果页面完成下一个ajax调用时会返回结果。
It could also be considered using WebSockets. In a sense that the Webserver itself could tell the browser when it is done processing the query execution as it offers full-duplex communications channels.
也可以考虑使用WebSockets。从某种意义上说,Web服务器本身可以告诉浏览器何时完成处理查询执行,因为它提供了全双工通信通道。