搞了次性能优化，结果出乎意料！

大家好，我是程序员鱼皮。

经过 2 个月的直播，我的 定制化代码生成项目 所有的核心功能已经开发完成，用户可以在线制作、分享、使用代码生成器~

目前项目已经进入了优化阶段。这次的系列教程中，我专门用了 4 个小时的直播，给大家带来了一场极致的 性能优化 “盛宴”。

很多同学由于没有实习或工作经历，可能没有接触过性能优化，但这却是能区分程序员水平的重要技能。

为什么这么说？

举个例子：

• 优秀的程序员，能用 1 台机器满足 10000 个用户的使用需求，如果满足不了，首先想到的是继续去优化。
• 而一般的程序员，用 1 台机器可能只能满足 1000 个用户的使用需求，如果满足不了，就要加机器、加资源。现实往往是没有资源给你加。

怎么区分一个程序员有没有性能优化经验呢？

就先问大家一个问题吧：一台部署了 Tomcat 的服务器，每秒最多能处理多少个请求？

下面给大家简单分享下我直播中的性能优化过程，答案也将在最后揭晓。

性能优化实践

要优化的是一个后端查询接口，功能是查询出主页要展示的分页数据列表，逻辑很简单，就是数据库分页查询而已。

如下图：

首先我们往数据库里插入 10 万条数据，然后打开浏览器控制台，观察 10 次请求的响应耗时，平均是 700 毫秒：

1）首先，我尝试优化了数据查询的 SQL 语句，让它只查询需要返回给前端的数据，减少数据量。

优化后的接口平均耗时是 500 多毫秒，大概响应时长缩短了 1 / 4：

使用 JMeter 进行压力测试，每秒启动 1000 个线程，总共启动 1 万个线程发送请求，在异常率 0% 的前提下，测试结果得到的 qps 为 20，这显然不是一个很好的成绩。

2）进一步优化，使用性能更高的 Redis 分布式缓存。将分页查询结果作为 JSON 字符串写入缓存，再次查询的时候直接读取就行。

结果响应时长直接缩短到了平均 20 毫秒！缩短了 25 倍！

第一个请求是加载缓存的，所以较慢。

有缓存的情况下，压力测试得到的 qps 是 114.6，提升了 5 倍多！

可见缓存还是猛啊，读多写少、更新频率低、访问频率高的数据，非常适合使用缓存。

还能进一步优化么？

3）当然能！使用比分布式缓存更快的本地缓存，直接从当前服务器内存读取数据，更快~

用浏览器控制台测试响应时长，几乎没有变化（因为我测试过程中，Redis 也是本地启动的）：

进行压力测试，发现 qps 略有提升，大概 10% 左右吧：

本地缓存按道理来说已经是最快的读取方式了，难道这就已经优化到极限了么？

当然没有！

4）虽然 I / O 难以继续优化了，但我们可以优化程序的计算逻辑、节约 CPU 资源。

比如我修改缓存的数据类型，不再写入 JSON 格式的缓存了，直接用 JDK 原生的序列化方式去保存对象，这样读取的时候也不需要把 JSON 转为对象。

优化这个逻辑后，响应时长大幅度减少！平均 8 毫秒左右：

没想到吧，看似不起眼的 JSON 转换操作，这么影响性能？

压力测试的结果更恐怖了，吞吐量接近 16000，直接提升了 100 多倍！

真是不测不知道，一测吓一跳。

问题来了，还能继续优化么？

当然可以！

5）除了业务逻辑层，我们还可以优化请求层。比如修改 Tomcat 服务器的配置，增大工作线程数和最大线程连接数。

稍微改 2 行配置，吞吐量就提高了 1 / 5 左右，接近 19000！相比最开始的 qps 20 提升了近千倍！

这。。这次到极限了么？

我怎么知道啊！肯定还是需要自己测试这个极限到底在哪里！

如何测试呢？

6）我们可以编写一个没有任何业务逻辑，直接返回 "ok" 字符串的空接口。

每秒启动 10 万个线程来测试，得到的 qps 为 36000+，又提高了整整一倍！

ok，没有任何逻辑的接口 qps 是这个数，那么你再怎么优化业务逻辑，性能的极限也不会超过这个值。

那么，还有办法继续优化么？

当然可以！

7）因为这只是 Tomcat 服务器 + Spring MVC 框架的极限，如果我们用别的技术呢？

这里我就抛砖引玉，大家感兴趣的话，可以找个项目中的查询接口、用我上面提到的方法优化下。

回到最开始的问题 “一台部署了 Tomcat 的服务器，每秒最多能处理多少个请求？”

其实这个答案是 无解 ，因为缺少了最重要的测试条件、测试环境和测试基准，比如是在几核几 G、带宽多少的机器上测试呢？不同的测试环境，测试结果肯定不同。性能优化效果一定要以实际测试结果为准，下次遇到这种问题的时候，别被面试官唬住了哦~

以上就是本期分享，时间有限文章就只能讲这么多了