视频展示通过调整数据库连接池大小，将响应时间从100ms降低到3ms。内容探讨了CPU、磁盘和网络作为性能瓶颈，以及PostgreSQL的连接数计算公式。建议连接池大小为（核心数*2+有效磁盘数），并强调小连接池和等待队列的重要性，以避免不必要的数据库负担。
（因为这视频是英文解说且没有字幕，我替大家做一下简单的概括：）
视频中对Oracle数据库进行压力测试，9600并发线程进行数据库操作，每两次访问数据库的操作之间sleep 550ms，一开始设置的中间件线程池大小为2048：
压测跑起来之后是这个样子的：
每个请求要在连接池队列里等待33ms，获得连接后执行SQL需要77ms
此时数据库的等待事件是这个熊样的：
各种buffer busy waits，数据库CPU在95%左右（这张图里没截到CPU）
接下来，把中间件连接池减到1024（并发什么的都不变），性能数据变成了这样：
获取链接等待时长没怎么变，但是执行SQL的耗时减少了。
下面这张图，上半部分是wait，下半部分是吞吐量
能看到，中间件连接池从2048减半之后，吐吞量没变，但wait事件减少了一半。
接下来，把数据库连接池减到96，并发线程数仍然是9600不变。
队列平均等待1ms，执行SQL平均耗时2ms。
wait事件几乎没了，吞吐量上升。
没有调整任何其他东西，仅仅只是缩小了中间件层的数据库连接池，就把请求响应时间从100ms左右缩短到了3ms。
But why?
为什么nginx只用4个线程发挥出的性能就大大超越了100个进程的Apache HTTPD？回想一下计算机科学的基础知识，答案其实是很明显的。
即使是单核CPU
最低0.47元/天 解锁文章
扫一扫
298
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
