我做一个微信的小程序，秒并发量有1万左右，用了7台服务器，但是7台同时运行可以容纳的并发量反而不如一台的，这是为什么，一台服务器可以承受1~2千的并发量，7台应该刚刚好的。
用nginx做转发，等于反向代理。所有的请求都请求这一台nginx主机，有nginx平均分发给7台应用。压测1台服务器没有问题，压测多台时出现timeout
为什么会出现上述的情况呢？请各位大神指教，确认解决2000C奉上
只是一个参数配置问题，已经找到并解决了，并不是没有规划好，也不是优化的问题
首先，性能的瓶颈在哪里，是不是服务器的运算能力，还是别的地方？比如说火车站有大量旅客滞留，并不一定是火车车皮不够，也可能是铁路饱和了，没法加开火车，导致车皮放在车站走不了。
你如果网络带宽不足，服务器多，但是它们都是空转。你可以看下每个服务器的硬件占用情况。windows服务器可以用任务管理器，linux可以用top去看。
其次，你的并发架构是如何，你7个服务器是做应用层的负载均衡还是数据层的，有没有配置对，负载均衡是不是把请求分摊到所有的服务器上去了。
再其次，并非7个服务器就一定等于一个服务器的7倍。不能这么简单换算的。因为总有一些操作必须事务化，并且同步，不能并发执行。
还有，你是不是使用了高可用的方案，那些方案会将同样的操作放在不同服务器上做镜像冗余，一个服务器失效，服务不会中断，但是它不是为了提高性能而做的。冗余并不能发挥性能效应出来。
最后，还要看你是怎么测试的并发，你的测试本身有没有问题，是否科学，你的运营商有没有限制，等等。
应用服务器本身不会出现问题，所以当前果断怀疑数据库出现瓶颈，一秒钟并发了1W，这个数据量落到单机估计数据库就差不多要死了。和你说的现象很相似，七台服务器提供的能力和一台差不多。
建议：
1、给数据库添加监控
2、数据库分库分表，如果你们的业务是读多写少的场景，建议使用maxscale中间件进行读写分离，这个中间件我们在生产环境上用，效果还可以。或者直接把数据库换成mongo、tidb
3、sql优化，索引是否到位，单表容量是否到上限了，数据冷热分离
4、业务逻辑中一部分逻辑异步化，比如更新状态等更新数据库操作异步化。我这里提一种方案将变更信息打印到日志，然后从日志中使用ELK进行处理更新数据库