@iyaozhen 所以 20ms 的话，如果算上你电脑网络到机房的网络延迟，已经算是很低了，并且你离机房还比较近。。如果北京到广州，绝对不可能低于 30ms 的。

还有你说复杂点的数据结构就超过 100ms，这个根据你的描述，没法判定原因。你要先确定不是网络带宽原因，再去看是不是服务器或者数据库的问题。

@abcbuzhiming 看来你不了解压力测试。。如果是测性能，就要尽量减少网络和带宽的影响。。比如在阿里云同机房开一台测试。

如果你在本地测试，就要考虑网络和带宽的影响。。。比如你 ping 一下你的服务器，这个时间就是网络延迟，这个不能计算在内的。。。然后要考虑带宽，比如 1m 带宽，上行也就 120k 左右。。你如果有 120k 的数据，再怎么优化，也不可能低于 800ms 的。

@v2orz 看题主说的什么。。。从浏览器到服务器。。。难道他在阿里云上的浏览器做的测试？第一反应是在本地的浏览器吧。。。这个测试方法本来就有问题。

@v2orz 有什么不正常？网络延迟不计算吗？ 20 多 ms 的网络延迟已经很低了。。。又不是内网测试

@geeti 车三年一更换。。。真是有钱人。。。我感觉的我的车得开 10 年

@coolesting sqlmap

@coolesting

[12:06:35] [INFO] fetching tables for database: 'cms_db18595'
Database: cms_db18595
[13 tables]
+-----------+
| user |
| category |
| file |
| optionkv |
| record |
| recordkv |
| tag |
| tag_assoc |
| useract |
| userinfo |
| userkv |
| usermsg |
| usersess |
+-----------+


表示不明白你怎么修复的。。。。所有参数过滤一下，关掉报错提示就 ok 了。

@coolesting 然而并没有效果

Database: cms_db18595
Table: category
[5 columns]
+----------+-------------+
| Column | Type |
+----------+-------------+
| cid | int(11) |
| descript | varchar(60) |
| follow | int(11) |
| name | varchar(20) |
| number | tinyint(5) |
+----------+-------------+

@coolesting

[13 tables]
+-----------+
| user |
| category |
| file |
| optionkv |
| record |
| recordkv |
| tag |
| tag_assoc |
| useract |
| userinfo |
| userkv |
| usermsg |
| usersess |
+-----------+

是 cpu 性能过剩。。。gpu 和内存硬盘之类的，不存在性能过剩，性能越好，体验越好。。

密码竟然还是明文的。。。数据库竟然有 13 张表。。。能写这么多的表，没一点安全意识吗？

很多产品都有这种沙雕逻辑。。。更换手机号不允许用另外一种方式认证。就不考虑手机换号不用的情况

@ryd994 去掉通货膨胀，真的有加价吗？

@NotreDame 存在被破解的可能，但是就算破解也只能得到指纹的特征码，而不是图像。。通过特征码是无法还原出图像的。。

无 sim 卡确实是趋势。。技术上完全可以实现了。

助纣为虐也是没办法啊，企业永远无法对抗 zf 啊

和 23 楼观点一致，说简单点，如果程序没有太多依赖内存（比如某些内存缓存）。那么必然是第二种情况更好。单机架构永远没法和负载均衡相比。

如果代码中确实遇到相关问题的话，感觉需要工厂模式了啊。。。统一用一个方法来获得对象