p*****2
发帖数: 21240 | |
b***e
发帖数: 1419 | 2 Read it. thanks for the recommendation.
【在 p*****2 的大作中提到】
: 这个够讽刺的了
: https://coderbits.com/posts/9Zf20A
|
c****f
发帖数: 1102 | 3 expressjs 也就和sinatra 差不多等级
和full stack的rails比差远了
rails其他不说光一个Active Record就枪毙所有的ORM expressjs+sequelize在代码开
发速度上和rails比真的是差的不是一点两点
说白了 最现成的模式就是ROR快速做一个出来 等网站有规模了需要速度了 再花钱找人
用node重写就是了
小中型网站根本没必要用node写 纯给自己找不自在lol |
p*****2
发帖数: 21240 | 4
how about MEAN stack and SPA?
【在 c****f 的大作中提到】
: expressjs 也就和sinatra 差不多等级
: 和full stack的rails比差远了
: rails其他不说光一个Active Record就枪毙所有的ORM expressjs+sequelize在代码开
: 发速度上和rails比真的是差的不是一点两点
: 说白了 最现成的模式就是ROR快速做一个出来 等网站有规模了需要速度了 再花钱找人
: 用node重写就是了
: 小中型网站根本没必要用node写 纯给自己找不自在lol
|
b***e
发帖数: 1419 | 5 如果一定要relational. ..
【在 p*****2 的大作中提到】
:
: how about MEAN stack and SPA?
|
p*****2
发帖数: 21240 | 6
我感觉用Node就要走Mongo这条路才有优势。
【在 b***e 的大作中提到】
: 如果一定要relational. ..
|
p*****2
发帖数: 21240 | 7
大牛怎么解释新一批的startup以python为主呢？
【在 c****f 的大作中提到】
: expressjs 也就和sinatra 差不多等级
: 和full stack的rails比差远了
: rails其他不说光一个Active Record就枪毙所有的ORM expressjs+sequelize在代码开
: 发速度上和rails比真的是差的不是一点两点
: 说白了 最现成的模式就是ROR快速做一个出来 等网站有规模了需要速度了 再花钱找人
: 用node重写就是了
: 小中型网站根本没必要用node写 纯给自己找不自在lol
|
b***e
发帖数: 1419 | 8 I could agree with you. But it can't be that PayPal and Groupon uses of
node are all Mongo based. and I don't believe node wants to shut the door
to relational and transactional applications.
【在 p*****2 的大作中提到】
:
: 大牛怎么解释新一批的startup以python为主呢？
|
p*****2
发帖数: 21240 | 9
Node也可以连relational。Paypal不清楚, Groupon目前主要是在frontend那边用Node
，并没有深入到backend。据我所知，walmart也是一样的。像这些大项目很难全部迁移
到node上去，而且也没有必要。我更关注的是新的startup使用MEAN,或者类似stack的
情况。
【在 b***e 的大作中提到】
: I could agree with you. But it can't be that PayPal and Groupon uses of
: node are all Mongo based. and I don't believe node wants to shut the door
: to relational and transactional applications.
|
b***e
发帖数: 1419 | 10 有道理。
Node
【在 p*****2 的大作中提到】
:
: Node也可以连relational。Paypal不清楚, Groupon目前主要是在frontend那边用Node
: ，并没有深入到backend。据我所知，walmart也是一样的。像这些大项目很难全部迁移
: 到node上去，而且也没有必要。我更关注的是新的startup使用MEAN,或者类似stack的
: 情况。
|
|
|
g*****g
发帖数: 34805 | 11 知名项目还没听说那个后端大规模用node的。
Node
【在 p*****2 的大作中提到】
:
: Node也可以连relational。Paypal不清楚, Groupon目前主要是在frontend那边用Node
: ，并没有深入到backend。据我所知，walmart也是一样的。像这些大项目很难全部迁移
: 到node上去，而且也没有必要。我更关注的是新的startup使用MEAN,或者类似stack的
: 情况。
|
p*****2
发帖数: 21240 | 12
所以还有的发展呢。我觉得最先出现的知名项目应该在startup出现。
【在 g*****g 的大作中提到】
: 知名项目还没听说那个后端大规模用node的。
:
: Node
|
a***n
发帖数: 538 | 13
startup主要是用django吧。
【在 p*****2 的大作中提到】
:
: 所以还有的发展呢。我觉得最先出现的知名项目应该在startup出现。
|
p*****2
发帖数: 21240 | 14
这一批确实是。
【在 a***n 的大作中提到】
:
: startup主要是用django吧。
|
a***n
发帖数: 538 | 15 async的写法确实比较难吧。最近在改一个完全用select写的python库,恶心死了。 |
p*****2
发帖数: 21240 | 16
python不熟。node习惯一下还好了。Douglas 也认为单线程比多线程容易。没有race
condition，deadlock这些呀。
【在 a***n 的大作中提到】
: async的写法确实比较难吧。最近在改一个完全用select写的python库,恶心死了。
|
g*****g
发帖数: 34805 | 17 我提过很多次，哪有那么多复杂多线程的应用。互联网应用大部分用户是不相干的，相
干的部分冲突在关系数据库解决。
经典的例子就是卖东西的网站。
【在 p*****2 的大作中提到】
:
: python不熟。node习惯一下还好了。Douglas 也认为单线程比多线程容易。没有race
: condition，deadlock这些呀。
|
a***n
发帖数: 538 | 18 显然是多线程和coroutine简单，async的程序调试起来太费脑力了。
不用锁的多线程确实很难，特别是乱序执行，不过一般情况也没有必要。 |
p*****2
发帖数: 21240 | 19
我觉得也不一定。比如你想想你自己是单线程还是多线程的，你是同步的还是异步的。
【在 a***n 的大作中提到】
: 显然是多线程和coroutine简单，async的程序调试起来太费脑力了。
: 不用锁的多线程确实很难，特别是乱序执行，不过一般情况也没有必要。
|
p*****2
发帖数: 21240 | 20
大牛又忘记高并发了？
【在 g*****g 的大作中提到】
: 我提过很多次，哪有那么多复杂多线程的应用。互联网应用大部分用户是不相干的，相
: 干的部分冲突在关系数据库解决。
: 经典的例子就是卖东西的网站。
|
|
|
a***n
发帖数: 538 | 21
python可以用gevent, greenlet, stackless。
有钱的话就直接多进程。
【在 p*****2 的大作中提到】
:
: 大牛又忘记高并发了？
|
p*****2
发帖数: 21240 | 22
能说几个用的公司吗？
【在 a***n 的大作中提到】
:
: python可以用gevent, greenlet, stackless。
: 有钱的话就直接多进程。
|
g*****g
发帖数: 34805 | 23 高并发跟race condition, dead lock有啥关系？我有个echo service, 你给我每秒来
一亿个request也没race condition. 你要是说async可以提高throughput那是另一回事
，你举例不当呀。
【在 p*****2 的大作中提到】
:
: 能说几个用的公司吗？
|
p*****2
发帖数: 21240 | 24
我是说async的优势在高并发呀。所以现在即使Java也搞async呀。现在不是比较sync和
async吗
【在 g*****g 的大作中提到】
: 高并发跟race condition, dead lock有啥关系？我有个echo service, 你给我每秒来
: 一亿个request也没race condition. 你要是说async可以提高throughput那是另一回事
: ，你举例不当呀。
|
g*****g
发帖数: 34805 | 25 race condition, dead lock是你举的例子，所以我才有此问。async 的架构诸如netty
已经有了很久，就我的经验看，只有特定应用有必要。总的来说，这年头硬件白菜，追
求的是快速开发和系统稳定。node在前段快速开发这个没得说，是优势，后端系统稳定
这个还欠着火候，所以我不看好。
【在 p*****2 的大作中提到】
:
: 我是说async的优势在高并发呀。所以现在即使Java也搞async呀。现在不是比较sync和
: async吗
|
a***n
发帖数: 538 | 26
用python的公司还是用多进程吧，内存确实便宜。
特别是web也不是所有用户同时并发的。做其他需要不断连着的服务器asnyc有点优势。
【在 p*****2 的大作中提到】
:
: 我是说async的优势在高并发呀。所以现在即使Java也搞async呀。现在不是比较sync和
: async吗
|
l**********n
发帖数: 8443 | |
p*****2
发帖数: 21240 | 28
netty
race condition, dead lock也是异步的优势。node还是很年轻的，我觉得未来还是能
占据一定市场的，尤其是startup。
【在 g*****g 的大作中提到】
: race condition, dead lock是你举的例子，所以我才有此问。async 的架构诸如netty
: 已经有了很久，就我的经验看，只有特定应用有必要。总的来说，这年头硬件白菜，追
: 求的是快速开发和系统稳定。node在前段快速开发这个没得说，是优势，后端系统稳定
: 这个还欠着火候，所以我不看好。
|
p*****2
发帖数: 21240 | 29
async的性能比多进程好多了。
【在 a***n 的大作中提到】
:
: 用python的公司还是用多进程吧，内存确实便宜。
: 特别是web也不是所有用户同时并发的。做其他需要不断连着的服务器asnyc有点优势。
|
p*****2
发帖数: 21240 | 30
play我用过，这也是为什么我要转到node的原因。
【在 l**********n 的大作中提到】
: http://www.playframework.com/
|
|
|
l**********n
发帖数: 8443 | |
a***n
发帖数: 538 | 32
现在的服务器有几百个进程对效率没有什么影响。Mongodb是用线程的，1，2千的同时
链接我也没有看出来性能有什么问题。
除了websocket用异步有点优势，其他web用异步真的是没事找事。
【在 p*****2 的大作中提到】
:
: play我用过，这也是为什么我要转到node的原因。
|
a***n
发帖数: 538 | |
p*****2
发帖数: 21240 | 34
你要是这么说就没意思了。
【在 a***n 的大作中提到】
: http://blog.kgriffs.com/2012/10/23/python-vs-node-vs-pypy.html
: 1000个并发，node对pypy同步一点优势都没有
|
z****e
发帖数: 54598 | 35 https://github.com/adamjodlowski/nodejs-vs-vertx
node在高并发时候会有一些不响应
代码都有，自己跑一下就清楚了
【在 p*****2 的大作中提到】
:
: 你要是这么说就没意思了。
|
p*****2
发帖数: 21240 | 36
大牛没看出来这个是用来黑vertx的？
【在 z****e 的大作中提到】
: https://github.com/adamjodlowski/nodejs-vs-vertx
: node在高并发时候会有一些不响应
: 代码都有，自己跑一下就清楚了
|
q*c
发帖数: 9453 | 37 nested callback 也够你喝一壶的。
callback 就是 goto, 多了没法整。 人脑功能有限， 太灵活的东西撑不住。
【在 p*****2 的大作中提到】
:
: 大牛没看出来这个是用来黑vertx的？
|
g*****g
发帖数: 34805 | 38 没看出来，你给讲讲？
Dummy database constrained benchmarks favors 3x vert.x over Node.js.
As for 'requests per second' it's 3.5x faster (7x using both processor cores
, but this is unfair).
Vert.x sent more data down the tubes, I suppose it's caused by different '
Date' header formatting (it uses Rhino's NativeDate instead of JavaScript's
Date) . It also prints slightly longer 'X-Response-Timeout' (e.g. 13.0
instead of 13). I might look into it in the future. I tried to even out
basic benchmarks by adding extra data to headers. The problem is, vert.x's
database persistor uses different/longer '_id' format (looks like some kind
of UUID) than Mongoose, the 'Date' string returned is longer as well.
Native string manipulation (simple concat) in V8 seems faster than JVM's.
It looks like recursive Fibonacci's fans should go with Node.js.
【在 p*****2 的大作中提到】
:
: 大牛没看出来这个是用来黑vertx的？
|
c******o
发帖数: 1277 | 39 对了，async的东西主要是对资源利用率高。
我们现在的scala server,有load,CPU利用率可以达到100%
加上在AWS上自动scale,基本上完全是要用多少拿多少，有多少就可以用多少。 |
g*****g
发帖数: 34805 | 40 Your latency will increase quickly on more traffic if cpu usage is 100%.
Why are you not keeping it at more comfortable level? It takes a few min to
scale up.
【在 c******o 的大作中提到】
: 对了，async的东西主要是对资源利用率高。
: 我们现在的scala server,有load,CPU利用率可以达到100%
: 加上在AWS上自动scale,基本上完全是要用多少拿多少，有多少就可以用多少。
|
|
|
p*****2
发帖数: 21240 | 41
我个人感觉还真没你说的那么严重。完全可以manage的。
【在 q*c 的大作中提到】
: nested callback 也够你喝一壶的。
: callback 就是 goto, 多了没法整。 人脑功能有限， 太灵活的东西撑不住。
|
p*****2
发帖数: 21240 | 42
cores
s
kind
大牛没看出来那不是很正常吗？
【在 g*****g 的大作中提到】
: 没看出来，你给讲讲？
: Dummy database constrained benchmarks favors 3x vert.x over Node.js.
: As for 'requests per second' it's 3.5x faster (7x using both processor cores
: , but this is unfair).
: Vert.x sent more data down the tubes, I suppose it's caused by different '
: Date' header formatting (it uses Rhino's NativeDate instead of JavaScript's
: Date) . It also prints slightly longer 'X-Response-Timeout' (e.g. 13.0
: instead of 13). I might look into it in the future. I tried to even out
: basic benchmarks by adding extra data to headers. The problem is, vert.x's
: database persistor uses different/longer '_id' format (looks like some kind
|
p*****2
发帖数: 21240 | 43
to
说可以达到但是不会让他到100%的。到之前就加machine了。
【在 g*****g 的大作中提到】
: Your latency will increase quickly on more traffic if cpu usage is 100%.
: Why are you not keeping it at more comfortable level? It takes a few min to
: scale up.
|
n****1
发帖数: 1136 | 44 Async library的runtime里面喜欢用些自旋锁之类的, 所以有时候表面上看起来是
cpu100%运行, 其实只是不停地在pull
【在 c******o 的大作中提到】
: 对了，async的东西主要是对资源利用率高。
: 我们现在的scala server,有load,CPU利用率可以达到100%
: 加上在AWS上自动scale,基本上完全是要用多少拿多少，有多少就可以用多少。
|
b*******s
发帖数: 5216 | 45 自旋锁未必效率不高
【在 n****1 的大作中提到】
: Async library的runtime里面喜欢用些自旋锁之类的, 所以有时候表面上看起来是
: cpu100%运行, 其实只是不停地在pull
|
n****1
发帖数: 1136 | 46 是的， 只是CPU数字有点deceptive
【在 b*******s 的大作中提到】
: 自旋锁未必效率不高
|
