#1 调用数据库过多
我们见到的最多的问题是，每次请求或事务，查询数据库的次数太多。这有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/
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/changjianghoulang168/archive/2010/08/12/5808052.aspx