Asp.Net Chat 服务器端轮询
你好，
我使用 Comet 实现了一个聊天应用程序。 该请求在服务器上“挂起”，直到新消息到达。 然后，它带着新消息返回给客户端，并再次发送给服务器。
我的问题是：
为了检查新消息，我每 600 毫秒轮询一次数据库。 我执行一个简单的查询“select...from messages where messageId > ' + lastMessageId”。
此外，为了保持存在，我非常（非常）频繁地更新数据库 与每个用户“LastKeepAliveTime”。
SQL Server 事务日志变得越来越大，并且在某个时刻，我的聊天应用程序停止工作。
聊天用户不是注册用户，他们只是可以随时离开页面的随机用户。
谢谢 亚龙
Helo,
I have implemented a chat application using Comet.
the request is "hang" on the server until new messages arive.
It, then, returns to the client with the new messages, and goes to the server again.
My problem is:
In order to check for new messages, I poll the database every 600 ms.
I perform a simple query "select...from messages where messageId > ' + lastMessageId.
In addition, in order to maintain presence, I update the database very (very) often
with each user "LastKeepAliveTime".
The SQL Server transaction log is growing huge, and, at a certain point, my chat application stops working.
The chat users are not registered users, they are just random users who can leave the page at any time.
thanks
Yaron
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以下是防止事务日志失控的方法： http://support.microsoft.com/kb /873235
该文章中的选项包括：
等等。
作为旁注，可能值得设置用户列表及其最后活动日期，并将其作为对象存储在应用程序状态中。以这种方式访问会更快，并且您可以不太频繁地保留这些值。
Here's how to keep the transaction log from getting out of control: http://support.microsoft.com/kb/873235
Options in that article include:
and more.
As a side note, it may be worthwhile to set up a list of users and their last activity dates that you store as objects in your application state. It would be quicker to access that way and you could persist the values less frequently.
从完整模式事务日志切换到简单模式应该可以解决日志增长问题。
不过，我还应该补充一点，如果可以的话，避免轮询通常是一个好主意，因为它不可扩展。您可以考虑使用 Service Broker 或
SqlDependency切换到事件驱动模型。还有其他保持活动的方法。Switching from full mode transaction log to simple mode should solve your log growth issues.
However, I should also add that it's generally a good idea to avoid polling if you can, since it's not scalable. You might consider switching to an event-driven model using Service Broker or
SqlDependency. There are other approaches to keep-alives, too.您可以使用公共缓存对象来存储最后的保持活动信息吗？看起来信息量很小，你可以避免大量的 sql 更新。
Could you use a common cache object for the last keep alive information? It seems like its a small amount of information and you could avoid a lot of sql updates.