seedhk

@hgw514 我只是为了说明小规模公司不在乎这点速度，随便举的一个例子，没有数据支持，也没有具体案例。

i 系列的二手，从我几个做二手生意的同学那来看，还是很有竞争力的，买的人大多是女生。

至于价格，现在 M 系列的 mac 都没那么值钱了。更别谈性能比不上，风扇还狂转的 i 系列的了。。。

从小规模公司的角度来看，他们不需要各种奇怪的技术，也不需要多高端的东西。一个功能，用 java 实现和用 C++实现，最终可能 java 只慢了几百毫秒，小规模公司在乎吗？

他们只要求两个点：简单，快速，好用

从这个角度去分析，jspring 全家桶，尤其是 springboot 的这套东西，以其丰富的社区生态内容(C*DN 一定程度上也算)和简单易用的特性，会受到小规模公司的钟爱。

多数据源吧，有现成的(mybatis-plus 有一款多数据源的插件)可以直接用

接 #21

如果 你是按照 #18 的写法的话，那么讨论的问题其实是，客户端最多能同时向外发送多少个请求，从这个角度来说，你说的确实没错。

但是这和 nginx 有啥关系呢

班门弄斧一下，有问题请指正：

"可用端口最多 65535."

1. 就像 1 楼 说的：
站在服务器接收数据的角度，一般都是指定某个端口，比如 80 端口用于接收请求。

可用端口数是站在客户端的角度来说的，因为客户端发起一个请求，除非绑定了端口，否则都是随机选择一个高位端口。


"那理论上短链接最大 TPS 只有 65535/30=2184"

2.TCP 通过四元组确定一个链接是否重用

源 IP 地址 (srcIp)
源端口号 (srcPort)
目的 IP 地址 (dstIp)
目的端口号 (dstPort)
对于服务器来说，dstIp 和 dstPort 是固定的，而 srcIp 和 srcPort 是可变的。

所以，在 IPV4 中，绝对理想的情况下（不考虑操作系统，内存大小，请求耗时，请求大小，time_wait 等）
一个服务端能接受的最大请求数应该是：

客户端 ip 数×客户端 port 数


#10
"nginx 不是服务端呀, nginx 是做反向代理, 是客户端"

nginx 作为反向代理接收数据时，这时候他就已经是“服务端”了，绑定了某个端口(比如 80)

已收藏，感谢

只是单纯的接口信息的话，前面接个 nginx ，nginx 来统计，日志记下来后接 ELK 分析查询

支持！ 同时催更关于 windows 使用方案，尤其是隐私保护这部分的内容。