10个影响性能的问题

在最新一期的瑞士电脑杂志中，我们列出了这些年，用我们的客户端所遇到的10 个影响性能的突出问题。我希望这个列表能够给大家启发。同时，为了更好的了解怎样解决这些问题，我引入了这些博客的链接。

    #1 调用数据库过多

     我们见到的最多的问题是，每次请求或事务，查询数据库的次数太多。这有3种特殊的现象来证实。

1. 在当前事务的上下文中，请求的数据多于实际需要的数据。例如：请求所有用户 信息而不是那些我们要显示到当前屏幕的信息。
2. 同样的数据被请求多次。这通常发生在不同的组件在同一个事务中彼此独立的调 用，并且每次都请求同类数据。因为不知道哪种类型的数据已经加载到当前的上下文中，最终导致多次相同的查询。
3. 为了取得一特定的数据集执行多次查询操作。这通常是因为没有充分利用复杂 sql语句的优点或存储过程导致的。

想了解更多，请查看： Blog on Linq2Sql Performance Issues on Database ,  Video on Performance Anti-Patterns

    #2 同步死锁

    毫无疑问，同步在应用中保护共享数据是十分必要的。但有很多开发者犯了过度使用同步的错误。例如：大量的代码序列被同步。低负载（开发者本地的机器上）时 性能不会出现问题。在高负载或生产环境中，同步过度使用会导致服务器性能和扩展性问题。

想了解更多哦，请查看：How to identify synchronization problems under load

      #3 与远程通道对话过多

    很多类库出现使得远程通信看起来小菜一碟。开发者调用本地和远程方法几乎没有什么不同。对远程调用的缺乏了解，使得大家 忘了 随着每次远程调用产生的诸如延迟、序列化、网络传输和内存消耗等问题。简单的使用这些技术导致这些远程边界穿插太多的调用，最终导致性能和扩展性问题。

想了解更多，请查看： Performance Considerations in Distributed Applications

     #4 错误的使用O/R-Mappers

      对象关系映射卸下了开发者肩膀上的重担-- 加载和在数据库中持久化对象。任何一种框架通常有很多配置选项来优化应用用例的对象关系映射的使用。错误的配置和不正确的使用框架本身过多，导致使用这些 框架的不可预料的性能和扩展性问题。确保你自己熟悉所有的配置项并且了解你所依靠的类库的内部。

想了解更多，请查看： Understanding Hibernate Session Cache , Understanding the Query Cache , Understanding the Second Level Cache

     #5 内存泄漏

      运行时环境的管理，像Java和.NET都有垃圾回收器帮助进行内存管理。但是，垃圾回收器却不能阻止内存泄漏。被遗忘的对象会驻留在内存中，最终导致内 存泄漏出现OutOfMemoryException。及时的释放掉对不再需要的对象的引用很重要。

想了解更多，请查看： Understanding and finding Memory Leaks

    #6 第三方代码或组件的问题

     没有人靠自己写一个新应用的所有功能。我们使用第三方的类库来加快我们的开发进度。我们在加快我们输出的同时，也增加了由这些组件带来的性能风险。尽管多 数的框架有很好的文档且经过十分彻底的测试，但不能保证这些框架适用于所有情况。他们经常被不正确的使用，或不经过测试就使用。所有，在引入你的代码之 前，要对所有这些框架进行深入的检查。

想了解更多，请查看： Top SharePoint Performance Mistakes

    #7 稀少资源的浪费使用

     像内存、CPU、I/O或数据库这类资源都是稀少的。对这些资源的浪费使用导致其他人不能调用这些资源，最终导致性能和扩张性问题。举个例子：数据库连接 时间太长。连接应该只有在真正需要的期间段使用。例如，查询时连接，然后把连接归还给连接池。我们经常看到在处理请求很早之前就请求连接，并且直到最后也 没有释放连接，这就导致瓶颈现象的出现。

想了解更多，请查看： Resource Leak detection in .NET Applications

    #8 臃肿的WEB前端

     由于网络的高速接入，用户有了更好的用户体验。不好的趋势是很多应用打包的东西太多，他们变得臃肿，最终导致浏览器出现错误。那些还没有高速网络接入的用 户会遇到这样的问题会最多。图片过大过多，错误的使用浏览器的缓存，过度的使用JavaScript或Ajax，所有这些都会导致浏览器的性能问题。按照 已有网站的成功案例来优化能解决这些问题。

想了解更多，请查看： How Better Caching would help speed up Frankfurt Airport Web Site

   #9 错误的缓存策略导致垃圾回收过度

    把对象在内存中缓存，来避免持续的对数据库的反复调用是提升性能的一种方法。缓存太多的对象，或者缓存的对象不是经常使用，会把缓存的优点变成缺点，因为 消耗的内存过多并且增加了GC的活动。在实现一个缓存策略之前，有应该知道那些对象应该缓存，哪些对象不应该缓存来避免这些性能和扩展性问题。

想了解更多，请查看：Java Memory Problems , Identify GC Bottlenecks in Distributed Applications

    #10 间歇性问题

    间歇性问题很难被发现。这些问题在输入特殊参数或一定负载时才会经常出现。测试覆盖要全面，功能测试、负载测试和性能测试都要覆盖到。这样才能在成为最用 用户遇到的问题之前发现这些问题。

想了解更多，请查看： Tracing Intermittent Errors by Lucy Monahan from Novell , How to find invisible performance problems

   （附加问题）#11 昂贵的序列化

    使用远程通信,像Web Service，RMI 或 WCF。对象需要被调用者序列化来在网络中传输。网络另一端的被调用者需要在使用这个对象前反序列化。传输时两端都这样做的话会导致一些资源消耗。知道两 端需要什么类型的序列化，哪种序列化和传输类型是最优的很重要。不同类型的序列化对性能、扩展性、内存使用和网络传输会产生不同的影响。

想了解更多，请查看：Performance Considerations in Distributed Applications

    本文摘自：http://blog.dynatrace.com/2010/06/15/top-10-performance-problems-taken-from-zappos-monster-and-co/

 

    翻译的不好，见谅。

评论

8 楼 lsl916201 2010-07-20  

很好，有帮助

7 楼 parabellum_sky 2010-07-19  

OOM太惹人烦了～！

6 楼 javamonkey 2010-07-19  

个人开发中有点体会
1)调用数据库过多:
一般俩种情况：一是O/R mapping工具，如果你不控制好join，那会调用很多此数据库
第二是开发者偷懒，用到什么数据再从数据库取。或者过于封装DAO也会导致此
2） 同步死锁
同步用的过多或者用的不好，经常导致 CPU 无法完全使用，可能只能用到10%。死锁 则直接造成了系统出问题

3） 内存泄漏
容易导致主机使用磁盘作为内存，这样降低性能，如果是java, 则导致虚拟机反复回收内存，性能自然降低

5 楼 sarstime 2010-07-19  

很不错的文章，总结的比较全面了，顶。

4 楼 happyxing 2010-07-16  

一直只注意其中的一部分，现在看看以后要更加注意了.

3 楼 constant 2010-07-16  

学习了。不错。

2 楼 mogui258 2010-07-14  

又是E文的了！ ！

1 楼 sishuien 2010-07-11  

很不错,确实都是很常见的问题