主题：关于系统性能的思考-----回复

看了《关于系统性能的思考》，结合自己平时的工作和身边的教训，谈谈自己的一些关于性能的想法

 

1.性能和容量不是一个概念，在相同条件下，当然性能如果越好，容量会越高

 

2.性能优化真的不是定式的，还需要相当丰富的经验去解决。以自己身边的系统为例，从Apache、Jboss、F5、网络、应用系统、到最后的DB，就如同是一条回家的路，任何一个环节处理慢了，都可能成为性能的瓶颈

 

3.一般涉及到性能的地方：

3.1.cache：缓存一切可以缓存的数据。比如数据字典、配置、读多写少的数据，但如果是敏感数据，比如资金，不建议缓存。

3.2.异步：异步一切可以异步的操作。意义不仅仅在于性能，更在于系统的可伸缩性

3.3DB：对于大表的查询，必须走上索引，不能全表查询；耗费性能的数据表操作，还需要控制频率

3.4jvm参数：不要忽视了jvm参数的力量，合理设置jvm三代空间的大小，对于gc，应该避免full gc，尽量minor gc，减少每次gc暂停的累计时间消耗，而且对于避免内存溢出也有帮助

3.5网络、负载均衡：F5也是有瓶颈的，至少我们遇到过。

3.6资源的创建：线程、网络连接、数据库连接等贵重资源纳入池中，避免每次使用时自己创建

3.7资源的参数：线程池中线程的多少、网络连接的超时时间、数据连接池的大小、数据库连接的block时间、prepared-cache-size，都是需要根据的具体的业务系统量身定制的。不要轻视，我见过很多系统在这些方面出过问题，性能问题导致可用率降低，都是血的教训啊！

3.8资源的合理利用： 说一个例子：对于一套时间比较久的应用系统，面对着不停更换的维护者，基于踩雷的风险，导致开发人员每次修改程序时都重新从DB、remote app中获取最新数据，导致了贵重资源的严重浪费。我见过一次业务连续查询同一用户的信息达8次的情况。不过有时也需要权衡，如果是访问量交大的业务，甚至可以牺牲代码的维护性保证资源的一次性获取；对于访问量比较小的业务，耗费点性能也未尝不可。

3.9java代码：基本类型、StringBuffer、ArrayList和HashMap的默认大小、常量、合理的synchronized，都是需要考虑的点

3.10其他：更多的需要具体的情况具体分析，有的甚至可以和业务pk获取系统更好的性能