如何在页面渲染后运行服务器端代码发送
我希望你们能帮忙解决这个问题:)
在我的页面在浏览器中呈现后我需要做一些事情。具体来说，我需要发送电子邮件/短信和其他非浏览器相关的内容，但操作需要时间，而且我不希望我的访问者等待 5-8 秒才能收到成功消息。
我尝试将“渲染后代码”放入页面卸载事件中。这似乎有效 - 但仅限于本地主机。它不适用于我们的生产服务器。
所以我想，也许这是一些 IIS 设置？ 我还读到，这取决于浏览器，它是否会在渲染完成后显示页面 - 或者等待整个包结束。
所以我试图在“ARC”之前用 Response.end 结束包，但这只是杀死了它。
你们对此有什么解释或理论吗？
i hope you guys can help with this :)
I need to do stuff after my page is rendered in the browser. In detail, i need to send email/sms and other non-browser related stuff, but the operation takes time, and i dont want my visitors waiting 5-8s for the success message.
I have tried putting the "After Rendering Code" in the page Unload event. That seems to work - but only on localhost. It does not work on our production server.
So i figgured, maybe this is some IIS setting? I've also read that it's up to the browser, if it will show th epage after rendering is complete - or wait for the whole package to end.
So i tried to end the package with Response.end before my "A-R-C", but that just killed it.
Do you guys have any explanations or theorys on how to this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
ThreadPool 线程可以帮助您实现此功能。
ThreadPool threads may help you implementing this functionality.
您可以创建一个新线程并在该线程上调用您的方法。
You can create a new Thread and call your method on that Thread.
您可能会考虑将电子邮件/短信与页面完全异步解耦，例如通过使用 MSMQ 队列。这样，您还可以以更稳健的方式处理电子邮件/短信，例如，如果 SMTP 服务器关闭或 SMS 网关繁忙，则在 10 分钟内重试。
编辑：回复：MSMQ 与线程/线程池 - 在大多数情况下使用新的工作线程也应该可以正常工作，但是，对于高端可扩展性，您可能会考虑 MSMQ 或类似的。
看看这个SO帖子这里
线程池（或线程）
- 更快、更容易实施
- 如果应用程序池被回收，未发送的短信/消息将丢失
- 会竞争线程（推荐使用自定义线程池）
MSMQ
- 需要更多工作 - 需要创建一个新的侦听器进程（例如使用 WCF）来处理消息
- 除非您可以控制服务器，否则可能很难托管
- 可以是事务性的和持久性的 - 即即使您的应用程序池被回收或服务器重新启动，未发送的消息也不会丢失。
- 可以对吞吐量进行更多控制 - 节流和延迟交付 - 例如，在价格便宜时在下班后发送短信
You might look at asynchronously decoupling the Email / SMSing from the page entirely, e.g. by using a MSMQ Queue. This way you will also be able to handle the Emails / SMS in a more robust manner, e.g. retry in 10 mins if the SMTP server is down or the SMS gateway is busy.
Edit : Re : MSMQ vs Thread / Threadpool - Using a new worker thread should also work fine in most cases, however, for high end scalability you might consider MSMQ or similar.
Have a look at this SO post here
Threadpool (or Thread)
- Quicker and easier to implement
- Unsent SMS's / messages will be lost if the App Pool is recycled
- Will compete for threads (recommend using a custom Threadpool)
MSMQ
- More work needed - will need to create a new listener process (e.g. use WCF) to process messages
- May be difficult to host unless you have control over the server
- Can be transactional and persistent - i.e. unsent messages won't be lost even if your App Pool is recycled or server reboots.
- Can exercise more control over throughput -throttling and delayed delivery - e.g. send SMS's after hours when it is cheaper