关键是现在的大部分框架都还不适合去做长连接这个任务，呵呵。

【 在 zms (来福) 的大作中提到: 】
: 我server自己用java写的，没用什么框架，可以支持大几千的长连接 （大概八千左右吧）
: 不过我的连接只推送东西，不读取
: cpu占用也不大，大概20%左右，感觉都是操作系统自己的占用（忙着发送东西）
: ...................
--
FROM 123.112.13.*

要等它们成熟起来才能用啊，嗯。
【 在 zms (来福) 的大作中提到: 】
: 还是有的，我知道的有
: resin/hessian stream  ,  jetty/continious  , tomcat/cometservlet
: 不过经我试用，都很naive
: ...................
--
FROM 123.112.13.*

nod 这是一部分 还有很大的一个部分是内存拷贝的开销 不考虑应用逻辑部分

【 在 zms (来福) 的大作中提到: 】
: 瓶颈不在 http的解析上，在 tcp/ip 栈的效率上
: 如果用好的tcpip栈，有明显的效果，比方说用freebsd
--
FROM 202.106.180.62

我觉得还是有很大差异的。
以我这边的逻辑来讲，客户端的时候：
解析命令：把一个char*转成结构体，CRC一下就行
发送，把一个结构做个CRC，转成char*
HTTP的
解析命令：内部肯定要把UTF8的东东转到UNICODE，我又要转成char*，然后还要解析这些字符串。
发送：把数据序列化成字符串，转成UTF8发送。

而且，单从带宽角度考虑，客户端能带的用户也应该达到HTTP的2倍才对。

【 在 JayXie (我是黑猫警长，专管花猫警察di~~) 的大作中提到: 】
: nod 这是一部分 还有很大的一个部分是内存拷贝的开销 不考虑应用逻辑部分
--
FROM 123.112.13.*

恩 在转来转去上消耗的太多肯定会影响效率了
如果直接改造lighttpd或者nginx来更简单点做的话 效率可能会提高很多
带宽到了那就没辙了 只能想办法压缩了 呵呵

【 在 ttl (小驴|主ID) 的大作中提到: 】
: socket明显不只6K个用户啊，我只是估算我那个应用HTTP长连接到6K用户就极限了。
--
修改:JayXie FROM 202.106.180.62
FROM 202.106.180.62