※ 引述《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 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.115.216.102 ※ 编辑: danny8376 来自: 140.115.216.102 (11/26 03:33)