这个方法的效率，呵呵，自己试试吧，几个人玩还是可以的。

这个问题当时我是这样解决的：

1. asp的内存存储对象可以用lock的方法避免并发时的写入冲突问题。

2.另外建立个内存数组存储每个在线用户已更新到哪一条消息即可。

不好意思，在楼上的回复中，您的问题我没有完全看清楚，您所担心的内存消息丢失问题，只要内存消息缓存充分大即可避免。

如果确实无法建立如此大的内存空间，也可以用数据库进一步辅助进行。但我认为作为webgame这个应用所附加的消息通讯来讲，现在服务器的内存空间是足够的，而且消息的重要性也不是很高，丢失部分消息的损失在可以承受的范围内。

  的确忘了WEB游戏里面聊天室的使用频率不高的这个现实....

还不至于低到这样的程度,虽然没有写例子测试,但是对比论坛的"短消息"承受能力还是应该不很小的.
一个游戏很难写的比这里论坛的数据种类和复杂程度多吧,discuz号称能承受天文数字的用户.

LS的方法貌似效率受到数据库本身实现的影响很大,米研究过数据库是否对经常操作的部分数据有什么特殊的优化方法,如果是实实在在的执行每条查询,的确效率有够低

回答正确  瓶颈在数据库
mysql对查询的效率还是很高的,还能全读到内存操作

XHR=XmlHttpRequest
ServerPush=HTTP长连接
MetaRefresh=<Meta refresh=...>

这些是不同的在客户端实现刷新的方式，在服务器端的角度来看，并和你开N个浏览器各自使劲按f5没有太大的本质区别。先撑不住的是服务器端，是底层软件为支持每一个并发连接的代价过高而无法负荷。也就是说，这个问题意味着的不是你的程序写得好不好，而是IIS/Apache/Tomcat本身及其架构本身在处理并发时是不是足够的好。

可以这么推算，针对每个并发的连接，单纯的静态页面会消耗多少内存，应用服务器又会消耗多少内存（这些都很好测）。实际应用中，大量的资源往往是被消耗在底层架构，而不是上层应用代码上。这就好比说，在底层一个并发连接在进入到你的代码之前自己就已经先消耗了比如说30M的内存，此时，你的程序再多消耗个1M或者2M的，其实关系不大。从这个意义上说，你程序的具体实现方式（Application也好，DB也罢）此时不是瓶颈的关键（当然，如果代码极度糟糕，资源消耗变成几十M的话，那就另当别论了）。除了内存因素外，并发中还有竟态，死锁，IO等等复杂问题，这些代码处理并发的质量（虽然你看不见它们），乃至整个应用框架本身的设计，也在很大程度上决定了最终的值。

根据我的经验，这些技术单机（2G内存）所能支持的并发数量大多都在100－500之间（不同技术，不同的优化程度，差异还是挺大的），不能满足将其作基础进行大规模应用的实际需要（这个值起码要达到1000才有基本的应用价值）。

[ 本帖最后由 jackyz 于 2008-1-18 13:16 编辑 ]

承受一堆不发帖的用户谁写的论坛都可以。

论坛的关键就在于大量帖子文本，还有就是主题和回复的逻辑树形结构的保存与显示。

在现有的sql数据库基础上，论坛程序也只是尽力优化而已。单表数量大了也只有分表等折衷手段解决，远无法达到天文的程度。

作为大量文本数据的论坛，依赖sql的全文检索的效率就更不值得一提了。

作为网游的聊天数据，具有实时性比论坛高，发言频率快，文本价值小，几乎无需检索等特点。不需要动用sql数据库存储。

谢谢，这三种当中ServerPush我没有使用过，不知道效果和特点如何。不过从名字判断，至少要长时间占用底层的连接，占用同时并发连接数。并且HTTP本身不被设计为长时间连接，最长稳定时间估计百秒级，不太够用。

个人感觉MetaRefresh肯定不如前面几种。

现在所谓AJAX主要就是XmlHttpRequest吗？前几天刚看了一篇IBM专家2005年的文章说用XHR+提前返回404还是30x代码方式加快无响应的请求的返回速度和服务器端资源占用，不知道这样的技巧有助于提高多少并发连接性能。

我没有对各种方法做过压力测试比较，但从我了解的数据来看，的确1000-2000可能是web服务器的上限了。IIS运行设置的连接数也就这么大，当然实际估计也用不到上限其他资源就满负载了。Apache我不太熟悉，不知道通过各种优化配置这个上限能突破到多少？

我想，这也是传统网游普遍采用编译服务器端的原因。但是本论坛既然为网页游戏，真正意义上的无端网页游戏瓶颈却限制于此了。

再插问一句，纯html静态服务器配置得好能容多少并发?

这个并发数应该会受到传输的文本的大小的影响吧,如果没记错的话,小于512字节的文本传输会非常迅速,大于512的话受到网络的影响回有较大延迟,而且如果网络环境不好,造成数据包被路由丢弃的话,那么延迟会更长.

关于长连接这个想问下哪里有相关资料,想看一下.

如果是rpg的webgame ，使用率也不低
至少猫游记是这样的

如果非常高的话,可以考虑专门用一台服务器来做聊天服务器的办法..

猫游记我没玩过，大概看了一下，界面。

不知道其中它的聊天采用什么技术实现的?

聊天在rpg的webgame中起到什么样的作用？npc的任务布置也是聊天吗？

@小黑，
长连接的相关资料可以 google "server push" 它是 http 规范的其中一种扩展。
MTU 概念对传输效率确有影响，但并非最关键的因素，512字节是经验值。
有专用于聊天的服务器，而且不会只有一台。

@榕龙，
纯静态 html 我听说能配到 4k+ 的并发。
类 RPG 的网游中“聊天功能”多用于“用户-用户”的交流，你也可以想象为一个聊天室。
webgame 中的 npc 任务布置应该与网络协议无关，通过网络传输的只是 npc 的状态。


专为聊天优化的应用多用Client端加插件的方式来实现（就是所谓的聊天加速器），这种情况下的服务端并不是web服务器，而是单独开端口在socket上自己构造协议（或直接用现有的协议，如XMPP，IRC，等）实现的聊天服务。如，新浪UC和网易聊天室都用了IRC。这样的服务器，单实例可以支持1k+的并发，单机可以支持到10k+。

换言之，现有的技术条件下，基于Web协议栈之上实现的聊天服务，很难做到较好的性价比。这就是为什么在现阶段，大规模的应用消息和聊天功能对于webgame还很困难的原因。