本帖最后由 qq_15313019 于 2014-12-06 20:06:23 编辑

解决方案 »

  1.   

    asp.net本来就是随时会重启的。不仅仅你说的所谓“崩溃”,其它无数原因也会造成重启。所以asp.net根本就不适合用用来做业务服务,asp.ne应该做门户网站。你的cpu占用太多,可能跟你处理每一个消息时做的冗余工作太多,或者是你的页面上发出了太多太多的请求。这是设计问题。不过这通常也是asp.net程序员所写的客户端的毛病。javascript程序员会写一个“纯的”富客户端“单页面”,仅仅轻量级地访问必要的几个ashx就够了。绝不刷新asp.net页面。
      

  2.   

    您好,现在用的是根据浏览器选择合适的保持连接的方式,websocket,longpolling等,保持长连接会消耗很多服务器资源从而导致CPU上升吗?我也看了很多使用socket.io实现的在线聊天,这也是一种类似我的方法的保持长连接的,看他们突破人数限制很容易啊,难道他们配置比我高?
      

  3.   

    给你个建议,自己开发 windows service服务(使用 HttpListener 类来提供一般请求),来支持 javascript 访问。另外就是将消息交互内容进行仔细设计和精简,保证“服务器推”消息,绝不用轮询的(比如说,那种号称会“自动选择http长连接”的SingnalR是混沌的,你只能在ie10上玩玩儿新鲜而已)。
      

  4.   


    长连接方式,“突破人数限制”的报道,基本上都是那些有着超过十万台服务器的大公司,而且从来也没有具体公布过真实的门户与应用之间连接方式,而且人家的门户也不是使用IIS+Asp.Net或者tomcat之类的,要么是大公司自己做的,要么就是非常精简的开源web服务程序代码上自己修改的。所以要越过 IIS、Asp.Net这些层次。
      

  5.   

    几年以前,我们也有一些年营业额十几亿、几十亿以上的大集团公司客户,于是我们那个公司就弄了几个人(最后其实是花钱买)坑爹的web网页的即时通讯程序,封装在winform窗体里面冒充c/s程序卖给人家。结果可想而知,人家单位随便试了两天,就完蛋了,上百分之一的用户量就根本不能服务了。是b/s程序就不要冒充c/s程序,是用于网页浏览的就不要冒充高性能通讯程序,是http长连接的就不要以为能够“暂时”跟websocket混合起来用。在自己公司里办公环境中当作玩具玩玩儿就行了。
      

  6.   

    现在也是深深体会了……这种项目第一次做,之前也做过大量的考察。但是,问题是,我现在并发量也就两三千,不可能这样的要求asp.net就不行了吧?