tornado 连续踩了两次坑，看来想驾驭好它还不容易啊

@deben 不平稳的请求数，在完全异步的 tornado 环境下，会导致 mysql 队列太长，最终请求超时，客户端发起重试，但 mysql 查询请求并未取消，然后就循环超时，高并发时快速失败是个问题，后来加了队列等待超时机制，然后又一波一波开始超时了，削峰又是个问题啊，异步的 mysql 操作，又有可能造成连接池获取连接死锁问题。。

decaywood

2016-03-16 23:02:27 +08:00

数据库读写分离，或者数据库单独起个服务， tornado 进行异步请求

sujin190

2016-03-16 23:10:03 +08:00

@decaywood 读写分离并不能解决这个问题，单独起个服务的话分明又加了个更复杂的问题，否则有 nginx 我为什么要用 tornado 呢？

CrazySpiderMan

2016-03-16 23:14:08 +08:00

Tornado 是垃圾, 用 Node.js

WildCat

2016-03-16 23:15:06 +08:00

Node.js 是垃圾，用 Golang

===

233

CrazySpiderMan

2016-03-16 23:16:58 +08:00

Golang 是垃圾, 用 Erlang.

CrazySpiderMan

2016-03-16 23:17:34 +08:00

Erlang 是垃圾, 用 Common Lisp.

CrazySpiderMan

2016-03-16 23:17:52 +08:00

Common Lisp 是垃圾, 用 Rust.

CrazySpiderMan

2016-03-16 23:18:07 +08:00

Rust 是垃圾, 用 Perl.

CrazySpiderMan

2016-03-16 23:18:24 +08:00

Perl 是垃圾, 用 PHP.

CrazySpiderMan

2016-03-16 23:18:46 +08:00

PHP 是垃圾, 用 Python.

sujin190

2016-03-16 23:25:35 +08:00

@CrazySpiderMan 用过 nodejs ，不得不说，没有 yield 的 nodejs 更坑，各种异常处理，查询数据库，麻烦死了，但是 tornado 遇到的问题，估计也会遇到吧

CrazySpiderMan

2016-03-16 23:32:59 +08:00

@sujin190 我用 Node.js, 在会一点 JavaScript 和看了一点 Node.js 的文档的情况下, 就写过蛮复杂的程序(github star ~= 1200), 用 Tornado, 光是文档我都很难看懂, 设计得极其丑陋, 曾用它开发过程序, 很早就弃坑了.

motecshine

2016-03-16 23:33:01 +08:00 via Android

mark 一下以后估计也会遇到

2016-03-17 00:23:57 +08:00

对于这种密集读写风暴还是应该交给上层处理，还有异步数据库驱动的确太坑。

cevincheung

2016-03-17 00:50:54 +08:00

所以还是中间件吧。要不 postgresql 欢迎你

lecher

2016-03-17 01:41:48 +08:00 via Android

数据库业务设计有问题，至少合理设计缓存处理可以做到 Web 读取的请求不需要穿透到数据库。

就数据库的处理性能而言，不应该比单机 Web 服务差，要是扛不住单机 Web 的请求，改改读写数据库的业务优化才是上策，一个每秒查询才几百就拖垮的数据库业务，用什么语言都一样会挂。

数据库扛每秒几千的请求才是合理的，正常的单机业务瓶颈应该出在带宽或者 Web 容器上。

janxin

2016-03-17 07:14:21 +08:00

@sujin190 上面都提到了，跟语言无关，还是架构设计的问题

clino

2016-03-17 08:44:40 +08:00 via Android

同感如果瓶颈在数据库上应该想办法做数据库优化
一个就是能不能配置 nginx 的访问频率限制呢

clino

2016-03-17 08:46:10 +08:00 via Android

@cevincheung postgres 这方面有什么好处？

deben

2016-03-17 08:58:21 +08:00

LS 的各位大神, 如果对于我这种外行人来做数据库频繁写入的业务, 会不会用类似阿里云的 RDS 这种产品会更少一些麻烦呢?

bobuick

2016-03-17 09:00:55 +08:00

RDS 只是机器性能方便扩展而已，数据库方面并没什么特别的。同样的配置该它瓶颈还是一样会瓶颈。
不然地球人就不用分表分库，做分布式分布数据了

lecher

2016-03-17 10:10:37 +08:00 via Android

RDS 用不好一样挂。
遇到过个电商团队问过类似的问题，他们才几万用户，每秒一百多 HTTP 请求，还是处理不过来，一查业务， SQL 读写处理各种多级联表，最多的有五级联表，如果都没有命中索引，五个 join 把五个表的记录一乘起来就是非常恐怖的运算量。

这种情况直接在数据库加冗余字段，减少联表查询，性能一下就上去了。能单表查询尽量单表查询，不行也要把索引规划好，减少联表的消耗。在加上缓存处理，把读取查询结果缓存在内存，数据库基本负载就都在处理写入，可以提高更多性能。

ainimuyan

2016-03-17 10:30:27 +08:00

@sujin190 有没测试过多少并发的时候开始出现这样的问题呢

justfly

2016-03-17 10:34:46 +08:00

你现在数据库是瓶颈了就去解决瓶颈的问题，就算不用异步的 MySQL 驱动，数据库到瓶颈不会出现这个问题，也会出现拒绝连接的问题

realpg

2016-03-17 10:50:18 +08:00

一看描述，就是不会写 SQL 的问题……
跟同步异步、 tornado 、 python 都没啥关系……

zhicheng

2016-03-17 11:58:02 +08:00

@realpg 见了少切肉剁到手嫌菜刀快的。

wingyiu

2016-03-17 12:15:16 +08:00

我们的 tornaod 的 sql 查询都是同步的，只要 sql 足够快， tornado 进程足够多，就没问题了。 py 异步 mysql 库还没有比较稳定健壮的吧

sujin190

2016-03-17 13:10:19 +08:00

@lecher 恩，测试下来， mysql 每次查询数确实过万的，没有 join 查询的话

sujin190

2016-03-17 13:13:49 +08:00

@ainimuyan 其实说起来 mysql 并未到瓶颈，测试下来，每秒过万查询完全没问题，只是 tornado 完全异步，确实查询数据库等待不接受其他连接这个缓冲，使得突然高并发削峰，连接管理上和同步模式有些不一样

sujin190

2016-03-17 13:15:08 +08:00

@wingyiu 是的，使用同步 sql 方式来管理思考查询过程，到了异步来说，似乎问题不太一样，也正在尝试调整

sujin190

2016-03-17 13:17:36 +08:00

@ainimuyan 并发其实不是太高，大概 300-600 左右吧，单机，只是因为我们客户端的原因，有时可能超过数倍，所以突然升高的负载会使得 mysql 连接管理，负载出现异样整个不可用，也正在调整尝试

strwei

2016-03-17 15:46:58 +08:00

本站用的就是 tornado ，你们有何异议

tempuseraccount

2016-03-17 16:01:27 +08:00

都是垃圾，用 C 从头写吧

xxxcat

2016-03-17 17:38:00 +08:00

曾经看到过一篇老外的文章，说是 python 的异步调用比同步调用的代价高很多，所以随着接近数据库瓶颈，异步会更容易出问题，我觉得访问量比较高的系统，框架就不应该直联数据库

sujin190

2016-03-17 18:48:14 +08:00

@xxxcat 多了很多 callback ，消耗时间自然多了很多

darkbill

2016-03-17 21:37:25 +08:00

Mark 一下～～

AndyCrz

2016-03-17 21:51:18 +08:00

我用 tornado 抗过大流量项目（其实也没没多少每天十万条写入），个人经验是这样， 80%是 Mysql 没有配置好，用 dbutils 维持一个连接池，数据用事务进行批量提交已经跑了一年多了，至今没出现过问题

zonghua

2016-03-17 21:58:50 +08:00

部署 py 的工程，因为配置的路径少了一条杠，耗费了我一个下午的时间。

alexapollo

2016-03-17 22:02:50 +08:00

明显是存储瓶颈，换 redis 就好了，或者加个缓存

alexapollo

2016-03-17 22:03:17 +08:00

no business with tornado

sujin190

2016-03-17 23:58:24 +08:00

@AndyCrz 我们现在已经数十万写入，数百万 request 了。。 dbutils 同步读写吧

AndyCrz

2016-03-18 09:14:39 +08:00

@sujin190 这种问题你确定是异步的问题吗？你测试了 profile 了？看一下数据库的 log 了

lixm

2016-03-18 10:14:16 +08:00

数据库这里慢，换什么都不行，把数据库的问题解决了，一切都 OK 了

clino

2016-03-18 16:30:00 +08:00

楼主我自己写了写代码来测试,异步用的是 gevent,感觉还好,如果故意在处理请求的时候改成比较慢的比如说等待一下 shell 子进程的结束等,确实数据库那边会有问题,但是只要调大一下连接池的最大连接数,然后再配置一个合适的数据库连接获取 timeout 的时间,虽然 rps 会变低很多,但是数据库这里不会抗不住才对呢

楼主你应该有用连接池吧?

我这里测试用的是 uliweb gevent sqlalchemy postgresql

dingyaguang117

2019-12-31 09:23:54 +08:00 via iPhone

单线程模型确实是很容易死锁的