看了一下场景的设计。这样的设计其实远远的脱离了实际的使用，所以产生的结果就很让人怀疑了。真实应用最常见的场景应该是有很多的跨表查询在里面的，而且关键业务的查询也不可能那么简单。在他的设计里面数据库消耗的时间基本上都是可以忽略不计了，单纯考虑架构的性能，当然得出这个结果了。但是实际应用中数据库消耗的时间是不能忽略的。

举个例子。第一个图表，最高的go一秒钟能处理10000个请求，等于是0.1毫秒一个请求。然后flask只能处理100个请求，等于是10毫秒一个请求。所以是1:100，但是如果那个数据库请求耗时增加到2毫秒的话，比例就是2.1:12了，如果增加到3毫秒的话就是3.1:13了。他的报表说白了也没错，只是说在现实中的差距远没有那么夸张就是了。

我觉得要测试的话至少要设计出类似电商网站的例子来，数据量要大到一定程度，然后至少两个场景。
1. 若干个查询条件，处理然后进行数据库查询，返回一个列表。输出应该是html，当然json也无差。
2. 查询某个商品，然后根据查询该商品相关的一系列表，然后返回结果。