有一个冲动,想用Node.js写一个静态web服务器,不知道有没有同类的产品了?(避免重复造轮子,也避免被骂臭显摆^_^)。刚才看到了 @朴灵 的nodev5 写的不错,不过略显简陋。
不知道express自带的静态服务器有没有满足你的需求 我自己写了个脚本利用express建立临时的静态服务器, 用来测试jquery和学习html5, 在这个层次的需求上是完全够用了的.
mongodb 会使用内存来缓冲数据,所以你可以把文件存在数据库里面, 利用mongodb天生的缓存机制就不用自己搞了,除非有很特别的需求. html分发就不懂了
@seasonx4 降低磁盘IO是目的,但是真实业务中并不能吧所有的数据写入内存,而是根据热度和业务的重要性进行cache。只是简单的吧文件写入内存是可以在一些场景打到cache的目的的。但是在复杂的业务中,就不好说了。
![nodejs vs php][1] [1]: http://cupic.img168.net/bbsfile/forum/201305/26/215834mzlt0dlpmosoeu6s.jpg ![nodejs vs nginx][2] [2]: http://cupic.img168.net/bbsfile/forum/201305/26/2158538suj9a8ajlsjjffl.jpg
在虚拟机测试的helloword,200个并发下的rps, 相同的网络io模型,性能差不多的语言,nodejs要稍逊于nginx,但灵活性与简单是nginx没法比的
var json='{"hello":"world"}';
response.write(josn);
response.end();
后面的测试是读入一个同样大小的html模板文件
LS这是在测试速度而不是负载能力吧... 参数很小 nginx直接调用操作系统级别的sendfile,静态HTML并发轻松上万无压力 如果是NODE则还要 1.一部分一部分把文件地从磁盘读取到内存 2.一部分一部分地转换为JS类型的BUFFER. 3.一部分一部分地扔给socket;上述每一步都要占用V8的主线程队列;
即使你不考虑CPU消耗,NODE也能应付足量的静态请求,但是无论如何跟NGINX没法比;建议把测试文件改成100MB再测试!看看CPU消耗和内存占用比,如果再把请求扩大10倍百倍呢?nginx可以轻松跑满G口带宽,NODE需要什么样的CPU才能跑满G口呢〜-〜
http://blog.std.in/2010/09/09/using-sendfile-with-nodejs/
对于系统api,应用程序nginx能调用,nodejs也可以调用,这能说明有什么优势呢?
@yuenshui 缓存静态文件可以考虑一下使用varnish之类的HTTP缓存工具,varnish的性能很强悍。官方号称:Varnish performs really, really well. It is usually bound by the speed of the network, effectivly turning performance into a non-issue. We’ve seen Varnish delivering 20 Gbps on regular off-the-shelf hardware.
@seasonx4 @anubiskong @yakczh 哈哈,node的文件处理确实很值得研究的,比如你们提到的sendfile,谁有解决方案或是使用经验以拿出来讲啊.
语言跟web 服务器不要混为一谈。Nodejs 没有最外层的包裹,很容易形成阻塞,或是当机。这也是我在考虑他能不能进行大规模开发的原因。上回一个做.net公司要把网站改成Nodejs 做。真是让我崩溃。现在的项目经理都不了解语言。看来都是靠忽悠。
其实我现在偏向的是前端angularjs 后端 Nodejs。反向代理图片等大数据的东西。。nodejs 专门做接口。和少量html代码的输出。其他请求都利用ajax。
@firstgeniusboy 这样可以,一般不是静态资源量特别大,那在nginx上加层缓存就够了。但如果需要用node做个文件服务器,估计就需要考虑更多的事情了,我对这个更感兴趣,但没实践过。
我看过一个测试帖子,说是静态文件nodejs比nginx更快,快大概1/5, 忘记了帖子的出处, 数据也可能不准确, 不知道事实到底如何. @sumory 你说的"文件操作的影响"又是什么呢?
@anubiskong 不是吧,不可能比nginx快啊。node是单线程的啊,文件操作会阻塞,以流的方式来操作的话,文件稍大一点也长时间占用处理时间。而且node的文件操作绕老绕去,没有sendfile的方式快(上文有提到过)。我暂时也只了解这么多,正好这段时间想多看下这方面。
@yakczh 这是常识不是辩论谢谢,你自己可以用10M带宽拖文件看看CPU占用比,推论一下便知 〜-〜 不懂那NODE跑G口是个夸张提法? 果然弱智怎么脑补都无济于事... 要反驳去反驳Twtter的测试报告吧 〜-〜
@seasonx4 这就是弱智的水平 ? 一会要别人提供AMAZON的云,一会儿又搬出个G口,最后狗急跳墙了,又拿twiter的测试报告来糖塞,既然有twiter测试报告,你就给出链接,可以做为一个参考,怎么又要别人提供云服务器,又要电脑g口,这逻辑是脑子被驴踢坏了吗?
@yakczh http://cnodejs.org/topic/51a35be9dc2eb34127049420 额。。我狗急跳墙,你想用就用呗,拦着你做啥。不过估计你也没啥项目~-~ NOOB 你好 NOOB 再见
@seasonx4 搞了半天,这就是你蹲在马桶上臆想出来结论的根据吧,你不是说有twiter 100m文件测试报告吗,怎么藏着掖着不拿出来,就这半屌子水平还出来丢人现眼? ,另外我用不用nodejs,有没有项目,跟nodejs的静态文件性能有什么逻辑关系和影响, 我用他就性能高了,我不用就性能低了?就这脑残逻辑还写代码?告诉你,nodejs性能是一个客观存在,跟半吊子用不用他,项目多少,半吊子靠臆想脑补的程度毛的关系都没有
@sumory 编译自己版本的NODE OR 用"binding"(也需要在JS里绕一圈,还不如直接用pipe这个功能,官方承诺速度会提升... 你是想省一个WEB SERVER吗 还是不要吧... Nginx能提供一定的防CC能力,不像这个论坛按F5就挂了〜-〜
@seasonx4 我的观点是什么? 你提出一个观点,应该由你来出具令人信服的证据,自己说服不了别人,就让别人出证明,法院抓人要给人定罪没辙了,是让罪犯自己证明自己有罪,这是你的脑残逻辑吗? 我引用了一个Sendfile的博客,你说是歪楼,从一开始让别人给你提供amzaon云,最后扯到做过项目多少,用nodejs不拦你,你这满地打滚的表演还嫌丢人丢得不够吗?你真把自己当坦克了啊? 我没有提出100m文件性能相关的观点,我凭什么给你论证它的对错,你自己傻,以为别人也跟你一样犯傻吗? 对于这种没有实际数据支撑的观点,科学的态度是不知道,任何观点都有待进一步的实践验证而不是象脑残一样到处满嘴跑火车, 放完空炮被人戳穿了然后满地打滚耍无赖,赖给别人来论证,脑子坏透了吗,但你有没有想过遇到别人脑子很清醒的情况呢
@seasonx4 这个论坛别人都是正常的讨论技术,就一个二货在别人讨论技术的时候扯什么歪楼+1,然后让他真正拿着干货出来的时候,推三阻四,顾左右而言他,嘴里除了冒点屎还是屎,憋半天憋不出一点有营养的东西,这种脑残见一个修理一个,出来一次修理一次,短路的的脑壳一定要修理好,不然下次别人在讨论技术,冷不丁还会冒出来歪脖子说歪楼+1
@firstgeniusboy 这个也是一个问题 我不知道目前大部分大量运用xhr的网站是怎么做的 我目前的做法是 判断uesrAgent 过滤几个搜索引擎的spider 把需要做seo的内容 填充到 模板返回
@seasonx4 用事实说话吧, 你提了一个观点, 别人要你证实你不(能)证实就是理亏, 别说什么云服务什么G口, 100M测不了难道10M不能测吗? 哪怕1M不也能说明一些问题吗? 网易的主页一共2M, 我感觉这样的需求倒是比100M典型. 如果自己就是不想/能测, 那你找到你说的那个报告也好. 如果你继续玩文字游戏, 那便胜负已分, 多说无益了.
@yjj676 提供了很不错的前端mvc解决方案,但是第一次用当然有点蒙。其实喜欢他的局部刷新机制。每次只是刷新页面的一部分 html,大部分的js 都是首次加载的。
NGINX低的不正常... 你的配置文件用的默认?
重点是, NODE 4核必然已经满载了,不信你可以打开TOP - 0查看 / 而NGINX CPU占用很低 当CPU是瓶颈的时候这个东西已经没有可以提升的空间了
看我的NGINX 单核近7000QPS
Server Software: nginx Server Hostname: 127.0.0.1 Server Port: 4000
Document Path: /robots.txt Document Length: 29 bytes
Concurrency Level: 10 Time taken for tests: 0.145 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 0 Total transferred: 269000 bytes HTML transferred: 29000 bytes Requests per second: 6911.76 [#/sec] (mean) Time per request: 1.447 [ms] (mean) Time per request: 0.145 [ms] (mean, across all concurrent requests) Transfer rate: 1815.69 [Kbytes/sec] received