※ 引述《howardwang (Howard)》之铭言：
: 想请教一个观念问题：
: 为了实作server push，
: 所以想知道，
: 有没有方法来解决comet或long polling时占用web server连线数的问题。
: 因为机器的capacity不大，系统也小，所以允许的同时连线数不多，
我只知道随便一台机器要来个上k的连线都不难
只是server端架设正不正确
如果你要用PHP+Apache这种方法直接玩long polling
资源消耗绝对除了浪费还是浪费
这只是方便而已
: 如果用comet的话，一个使用者就会一直占据client和server之间的一条连线，
: 这样子可能使用者会进不来网页，
: 后来听说了web socket，本来以为可以解决连线数的问题，
: 但看了一些网站之后，觉得web socket应该还是会占掉一条连线。
: 既然如此，为什么不要用AJAX+long polling就好了？
很简单long polling始终不是"双向"
连线数向来都不是问题真正重点
那些搞串流 搞即时通讯 更遑论是大型P2P
随便一个同时连线数对一般网页系统来说可能都是天文数字了
websocket主要特点在于它是个对HTTP扩充而成的"双向"连线
而不是原先HTTP那种客户端发请求 server只能被动回应的形式
long polling说实话只是种hack而已
当server端的push量一大的话
long polling会造成大量的request
(先不说比起websocket还可能有短暂断开的这个问题要额外处理)
这中间那大量header对server资源除了浪费外 还是浪费跟浪费
当然这边来看你指的连线数应该是PHP-FPM之类那种同时处理资料的连线...
不过会有这顾虑表示你从根本就选了不正确的方法
: 还是说，我的认知有错？web socket不会占住连线？
: 又或者，有不会一直占据连线的server push方法吗？
简单来说吧
你想要做一个server push的动作的话
后端架构请改用"常驻"模式的跑法 像是Java Servlet,Python,NodeJS,RoR这类
除非你打算让PHP也搞常驻
不过绝大多数的PHP都是被动式的服务
而所谓连线数的瓶颈在于这PHP解译器同时能执行的数量
当你后端改成"常驻"的模式后
正常写法会将server push这部分额外拆开处理
这时不管是处理long polling还是websocket的部分
除了最初判断request类型外
确定是server push的部分后就会把那连线丢到另一个pool里去让他wait
不去抢request解译那部份的资源(已经离开request解译部分)
而那pool里的东西只有要push的时候才另外拉出来把讯息给丢出去
不过这边很先入为主的认定原本是用PHP啦...
如果不是PHP状况也是一样
只是你处理上的观念要改变才行
并不是像以往写网页一样 等待只是放在那不输出
虽然long polling这样写也是能用 不过可以保证
没大网站是这样做的 因为那样server再多都不够用
: 谢谢。
打得其实有点乱XDD
对了 如果你是写网页放在一般的网页空间(一般的LAMP空间)
那根本上是无解的 因为架构打从一开始就不适合server push