如果适合，我想问下应该如何设置，或者说是运维，现在一到高并发（后续有数据库查询，美国服务器一次得 0.7S ），APP 端就卡住

“数据库查询，一次得 0.7S ”
那就不是 nginx apache 的锅了
去优化你的程序和数据库吧

你业务代码 /db 慢和 nginx/apache 有啥关系...

Apache、Nginx 只是前端代理转发，应用服务器得看你是什么语言实现的； Java 的话就是 Tomcat、jetty 或者 Spring Boot 集成的；你说的高并发是多少 TPS、QPS ？ 0.7S 也得看是哪里耗时最多？

所有学校的数据库课程，都教外连接之类的复杂查询。但在高性能应用中，复杂查询是要极力避免的。

应用服务器是 tomcat，0.7S 都是查询数据库时间，TPS 目前软件和我说是 100，但是服务器很渣，阿里云的最低配 2 个 CPU、8g 内存，在上面跑所有的服务。

现在我也在怀疑是 TCP 半连接的问题，因为我们的 APP 的应用场景是在网络极其不好的情况下打开。但是 windows 下没有找到怎么测试和统计。

0.7S 都是查询数据库时间，加个索引看看

看起来楼主对“病因”很清楚啊，那就对症下药嘛... 当然，生产机得谨慎，各种备份作好，先弄个类似的试验环境

我是搞嵌入式硬件的，只是对 TCP/UDP 比较熟，但是不懂软件的 Tomcat 什么的，所以我问问需要怎么设置。

数据库用什么？能查查它近期的 ops 统计信息么？
MySQL 的话，可以设置开启 慢查询 日志，记录超过你设定最小时长的查询语句。

1、app 是什么类型的 app ？ IO 密集型的还是做长链接的？
2、你理解的高并发是什么啊，ng 是 epoll/kqueue 实现的，网络 IO 复用。这跟你高并发毫无关系啊。
3、TCP 半链接堵塞没什么可能，除非 SYN 攻击，这个根本不是短板，listen 在 unix 记得是 64465 个(我也不确定)
4、我猜问题应该出在磁盘 IO。这个不是 IO 多路复用可以解决的问题，跟 nginx 和 apache 一点关系都没有啊。这个情况一定要开多线程 /进程，用异步。不然量一大，或者重接，mysql 被击穿，你客户端只会收到 504.。

说错了，大概是 65535，不记得了，这个问题你应该优化代码逻辑，尤其是数据库都读写，搞主从，reads 热缓存，等等都策略咯

新平台已经上了 reads 什么的啦，但是目前处在新老交替，老的目前还得维持一段时间，APP 是属于长连接模式，得到数据断开。磁盘 IO 有可能。另外我们的服务器由于好管理，用的 windows，不知道阿里云的 windows 是否有设置相关参数。

很多开发同学碰到 window 平台都是一脸懵逼~~我也是

老哥，这就尴尬了，windows 做 server 端我真没用过。只能说这大概是磁盘 IO 引起的，阿里云应该能看到相关数据图的，这个我真没了解过。真没有的话，你可以 psutil 这个库写个检测脚本的。

一般，nginx 就做前端的负载均衡，反相代理一下流量。你查询慢，要不是程序问题，比如查询 sql 不够优化，要不也可能是 db 负载太高了。
另外，为啥查询 0.7s ，app 就卡住了？你一次请求，就算 3-4s，app 也不会卡住吧？

1. keepalive 开起来
2. 内核参数把 tcp 复用和快速回收开一下，作为代理，nginx 基本上没什么问题了。
一条查询 0.7s ，本身就是很大的问题

golang
如果你不会 C C++ golang 爽到你爆

IIS6 都抗过 1241 每秒的请求压力。Nginx 可比它强多了。。。你这压力还不在 web server 上。

啥数据库，我 CentOS 7.5 下 Nginx + PHP 7 + Mariadb 10.3，每秒扛 2000 多请求没啥问题

优化数据库吧，如果你们没人做 dba 工作，那就上个中等的 rds, 先看看堆硬件能不能抗过去吧.
1. 要么花钱堆硬件
2. 要么花钱找人帮你们优化，
3. 要么花时间自己研究
三选一

连复杂 SQL 查询都学不会的人，确实不适合写代码

对啊。我发现学校里的东西和实际用的几乎不太一样

比如登入 APP 程序，刷新页面