java 并发编程实战这个书可以, 不过我也没看完, 因为很多通过 blog 都学了


JVM 就周志明写的书<深入理解 Java 虚拟机 2>就挺好的.

asyncio 不能降低你代码里单个 query 方法的耗时, 他要做的是用少量线程就能支撑超高的并发量,, 这个用线程是很难实现的, 单个请求的响应时间并不会变得更快,

gather 不是顺序执行, 都 asyncio 了, 只要里面 task 不阻塞, 就是异步执行的.

你这个没啥问题, 根据你加大到 1000 次, 差距挺大的, 所以应该是量不够大.

一个接口不可能这么高, 但是其他的接口也有网络 io, 和你测一个接口 1000 次概念差不多, 并发上去了, asyncio 性能差异就出来了..

如果只是一个接口, 没啥访问, 直接同步搞.. 简单

次数调大点试试. 看起来没啥问题. 可以把代码贴完整点, 包括 loop.run_until_complete()这一块

刚好你这个 task 里也是 5 个 sql 的 await.. :(

sorry, 理解错了.. 光看了你问题里写的 5 个 sql, 我漏看了下面的 gather, 你要问的是 gather 里的这 5 个 task 吧

nodejs 继续执行后面是因为你不用 await nodejs 的这个 promise, 而是等他返回结果返回后, 调用你注册的回调 function.去处理 function 果返回

nodejs 里, 如果你后续的执行依赖某个 nodejs 异步函数的结果, 那不还是得等异步函数结束拿到结果后再执行后面的结果吗.


1:
var s = asyncFunc(xxx, function (res) {
res 是这个函数的返回值.
}); // 不需要等待 asyncFunc 返回值,

xxx(); //


2:
var res = await asyncFunc(xxx); // 需要等待 asyncFunc 返回值
console.log(res)
xxx()

类似这两种方式.

你这代码逻辑上还是`同步`的, 因为你有 await, 会等待每个 sql 执行完成, 就是说一个 sql 执行完后才会去执行下一步的 sql. 只是你这个 sql 还没执行完的过程中, 线程不会卡在这里,, 而是会去执行其他的异步 task. 等你 await 的 task 返回后再继续执行你这个 task.

异步不是你理解的这样的异步. asyncio 的好处是异步 io 的并发..

with 或者 装饰器 ==, 可以搞成 java spring 事务这种方式.

通过启动变量.. 或者代码里写好, 根据启动参数里不同的 env 来使用不同的地址..

鲁迪的牙齿 做成的刀.

投诉, 你这个床太敷衍了... 连着淘宝一起投诉..

反正我 intel u 的有时候很烫..

这还能公开问? 生怕警察不知道你要去币安了??

基本每个大点的云服务上都有自己的 linux 优化版吧. 根据自己的硬件, 定制化一个能更好利用资源的版本.