分享“Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co”
Posted in architecture on 七月 12th, 2010 by kafka0102
Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co 一文总结了一些关于性能问题方面的经验，虽然不是很“新奇”，但也算是中规中矩的有借鉴意义，这里分享之。没有对原文做完全的翻译，也欢迎大家直接看看原文，本文转过来还夹杂了一些个人理解，有理解不当的地方也望指正。
1、Too Many Database Calls
这一问题是说在一次请求/事务处理过程中有太多次的数据库调用。典型的情景是：
1）请求了不必要的数据，比如程序员们为图省事而”select * ”出不必要的字段数据。
2）相同的数据被请求多次。这通常出现在同一事务中，彼此独立的组件需要请求相同的数据，而在不同的上下文下，程序员又没有检查出重复的执行情况。
3）为了获取特定的数据而使用了多次查询，这通常是没有有效的使用复杂的SQL或存储过程造成的（但话说两端，在一些反schema的表结构中，将复杂逻辑拆分成多条SQL是自然的）。
进一步阅读：Blog on Linq2Sql Performance Issues on Database, Video on Performance Anti-Patterns
2、Synchronized to Death
在应用中使用同步来保护共享数据是无可厚非的。不过，程序员们在使用同步时，往往没有经过深思熟虑而不恰当地增大了同步代码段的范围。因为同步引起的性能问题一般在低负载的测试环境中没有体现，但在高负载的生产环境就表现出性能及可扩展性问题。
进一步阅读：How to identify synchronization problems under load
3、Too chatty on the remoting channels
就开发来说，使用封装的API来处理远程调用就像处理本地调用一样简单。不过，它显然会比本地调用带来更多的问题，比如延迟性、数据的序列化、网络
流量、内存使用等等。当应用的远程调用层次过多，这些开销就需要考虑。这让我想起EJB2盛行的时候，即便是很普通的web应用也要整没用的分布式，活活
把性能降低好几个级别。
进一步阅读：Performance Considerations in Distributed Applications
4、Wrong usage of O/R-Mappers
ORM很好，能简化程序员的开发负担，不过它的复杂性会带来一些性能问题。像Hibernate等框架，通过优化配置及使用一些高级的trick，可以避免性能陷阱，不过这就对使用者有很高的技能要求。否则，对于有性能要求的应用，还是对ORM的使用谨慎些。
进一步阅读：Understanding Hibernate Session Cache, Understanding the Query Cache, Understanding the Second Level Cache
5、Memory Leaks
尽管像Java和.NET平台有垃圾回收器来管理内存，使程序员摆脱了C/C++中的内存泄漏噩梦。不过内存泄漏仍是可能的，如果应用抛出了OutOfMemoryException，那就需要好好看看哪些不需要的引用没有被释放掉。
进一步阅读：Understanding and finding Memory Leaks
6、Problematic 3rd Party Code/Components
在应用中使用第三方软件是很正常的，尤其是对于热衷于使用开源软件的Java社区。在选择第三方软件时，要谨慎的选择成熟稳定并经过细致调研的软件，而很多使用第三方软件引发的问题往往是使用者没有正确使用造成的。
进一步阅读：Top SharePoint Performance Mistakes
7、Wasteful handling of scarce resources
对于像内存、CPU、IO、文件句柄等资源，不正确地或浪费性的使用它们会导致性能及可扩展性问题。这方面的例子太多了，比如使用内存池、线程池、连接池等都是为了高效的使用这些资源。
进一步阅读：Resource Leak detection in .NET Applications
8、Bloated web frontends
当应用出现性能问题时，我们往往将注意力集中在后端存储访问方面，而忽视对前端的优化。现在对前端的优化有很多现成的经验，并且可以高快好省地提高效果，比如雅虎的优化原则、《高性能网站建设进阶指南》等优秀图书，都是前端开发人员需要掌握和应用的。
进一步阅读：How Better Caching would help speed up Frankfurt Airport Web Site
9、Wrong Cache Strategy leads to excessive Garbage Collection
对于解决存储访问的性能问题，很多时候都是在DB前架上Cache。不过，不恰当的Cache策略可能并不会带来明显的效果，所以需要对Cache策略及效果做好评估和验证。如果是在Java程序中使用Cache，就更要注意GC问题。
进一步阅读：Java Memory Problems, Identify GC Bottlenecks in Distributed Applications
10、Intermittent Problems
断断续续的问题。想让程序没有bug是很困难的，即便是很小的二分查找程序，也会在某个边界条件下出现异常。我们总能在生产环境中隔三差五的发现程
序的问题，有的甚至初看起来是诡异的。要保证程序质量，就需要在单元测试、功能测试、覆盖率测试、性能测试等环节上做足功夫，尽早发现问题，尽管这样也不
能保证程序在生产环境就没有诡异的问题。
进一步阅读：Tracing Intermittent Errors by Lucy Monahan from Novell, How to find invisible performance problems
11、(Bonus Problem) Expensive Serialization
题目说好是10个问题的，不过作者又买10赠1,搭了个零头。前面有提到远程调用是昂贵的，这里着重说的是传输数据的序列化和反序列化开销。一些复杂或者低效的传输协议和数据包格式（比如SOAP协议、XML格式等），可能就会产生严重的性能问题。
进一步阅读：Performance Considerations in Distributed Applications
最后，很推荐有兴趣的点击各条中的“进一步阅读”的相关链接，有的还不错。
=============================== 华丽的终止符 ================================
