先不说为什么走http，老板让我干啥我干啥。
每一条数据还是有点大。 每次请求一百条数据，大约9秒； 一千条数据的话就要40-几百秒了，这时就是看网络环境等各种因素了。
18万条 = 1800* 100 = 180* 1000;
我该是每次请求较少的条数，增加请求次数呢？ 还是增加请求条数，减少请求次数？
1)哪种方式好呢？ 2)使用for+setTimeout好呢，还是通过async.mapseries+深沉嵌套好呢 3)一下并发请求肯定不行吧 4)这种情况有啥推荐的方法
回复 (11)
I
丢mq里靠谱
A
请求100条数据指的是在一次请求里面响应100条数据吗？
M
我才用的第二种
S
引用 Acceptedlc请求100条数据指的是在一次请求里面响应100条数据吗？
@Acceptedlc 恩，一次请求响应回来一百条
S
引用 i5ting丢mq里靠谱
@i5ting 有什么推荐的包吗
I
引用 suntopo@i5ting 有什么推荐的包吗
@suntopo rabbitmq或kue都可以，你这个量不需要优化
J
难以想象100条数据就要8秒的时间，服务器响应是有多慢的啊，也可能数据量本身很复杂。推荐增加请求次数，因为每一条数据本身就比较大，对于v8内存占用非常严重的引擎来说减少数据处理量和前端体验成正比，其他引擎也是如此。同时对于JSON.parse来说，本身就比较慢，一旦数据量非常大，后果就可想而知了。
A
楼主，可以看一下相应一次的时候的内存使用量，感觉可能是内存用的多了，时间用来gc。可以增加请求次数，每次相应个10条试一下。还有@suntopo能说一下用mq的思路吗？谢谢拉
X
http 也有websocket 或者 socketio 啊。
D
网络不稳定还是先服务端 压缩一下数据吧。 请求方式 要是 客户端需求而定吧
P
关键是要搞清楚I/O的瓶颈在哪 假如上游接口，只能支持100qps，那么下游做什么都是徒劳 唯一能做的是，尽量保持稳定，请求接口温柔点~~~
或者，解决I/O瓶颈，那又是一个大话题
参与回复
登录后即可参与回复。登录