纯server push接口挂在那里的内存消耗反而是最低的瓶颈吧。
对于cgi接口，浏览器端执行纯JavaScript，大表要用几毫秒。
这样算来，单CPU的服务器，Node.js秒并发100就差不多了。
更不用说PHP了吧，如果不是restful而是server side sql，就更没边了吧。
难道业务逻辑都用c++写？或者不那么极端，Java这种预编译的，又能差多少？10倍？
再乘以8核得出C10K？
再说带宽。哪怕纯静态资源，就不说视频站、下载站了，只要不是纯文本，而是有图片的网页，哪怕按照一个客户端只占用1M带宽，阿里云能租到的最大带宽也只是200Mbit/s，而且已经是天价了。要C10K，意味着要10000Mbit/s甚至更高的带宽？除以8bit/Byte以后，SSD都难以达到1000MByte/s的访问速度吧？
莫非C10K这种理论瓶颈只是技术角度，实际上普通网站根本连这个边都摸不着？
正常算下来，中小站长承受范围内的VPS，能达到实际占用资源的秒并发100其实已经非常可观了。
换言之在融资前，初创项目根本不能计划更高并发的业务，那么换算成不那么均匀的日访问量/日活跃用户量，
（我估计也就1000日活跃用户，再高一遇到高峰就不能保持稳定体验了，1000用户访问碰巧都在一秒，大不了最多等10s；当然没这么巧，那就勉强算10000日活跃用户吧，稳妥PV也就再乘个10~100，满打满算100万PV吧），
也只是算小的项目吧，离融资阶段还没影呢？
还是说我最后一步换算有问题，C100~C1000的网站的日访问量/日活跃用户量已经非常可观了？
或者100万PV已经算大站了、支持融资或逐步靠广告自负盈亏渐入佳境了？
这也别谈ddos了，按住f5都受不了。
c10k(http://www.kegel.com/c10k.html)
原文中指的是client, 实践中我们使用连接数来代替, netstat -antp|wc -l 基本就是这个数字了.
c10k的意思就是单台server同时有超过10k个连接. 要强调的是: 这是一个技术指标, 而非业务指标.
qps
每秒请求数. 连接数对qps有影响, 但是更关键的因素是请求的处理时间. 处理时间越短qps越高.
一个普通的apache+php应用的连接数通常在100~300左右, 别说c10k, 能跑到c1k就是奇迹了.
通常的遇到cXXk问题的地方都是在负载均衡上, 比如lvs/haproxy/nginx..., 但是由于epoll的普及, cXXk的问题很大程度上已经得到了解决. c10k已经是上个世纪的问题了.
就我遇到情况, 目前应该更多关注qps, 而非并发连接数. 配置正常的情况下, 一般的业务连接数通常不会是问题.