之前我带大家做的代码生成器平台项目，用户可以在线制作、分享、使用代码生成器~
这次的系列教程中，我专门用了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框架的极限，如果我们用别的技术呢？
这里我就抛砖引玉，大家感兴趣的话，可以找个项目中的查询接口、用我上面提到的方法优化下。如果你有更多关于后端架构或Java应用性能提升的经验，欢迎到云栈社区交流分享。
回到最开始的问题“一台部署了Tomcat的服务器，每秒最多能处理多少个请求？”
其实这个答案是无解，因为缺少了最重要的测试条件、测试环境和测试基准，比如是在几核几G、带宽多少的机器上测试呢？不同的测试环境，测试结果肯定不同。性能优化效果一定要以实际测试结果为准，下次遇到这种问题的时候，别被面试官唬住了哦~
以上就是本期分享，时间有限文章就只能讲这么多了，大家如果对这个项目、这次的性能优化完整教程感兴趣，欢迎点击加入编程导航学习。这个项目视频教程接近40小时，文字教程十几万字，我付出了大量的头发精力，也保证绝对是一个很能打的项目~
发表于 10 小时前
|
查看: 1|
回复: 0
