本文来自于Bernd Greifeneder总结。旨在提醒自己养成习惯。
问题一：过多的数据库调用
在每次请求/事务中存在过多的数据库查询。
在一次事务上下文中所请求的数据比实际需要的数据多出很多。比如说：请求所有的账 户信息而不是仅仅查询出当前需要显示的信息。 多次请求同样的数据。这种情况通常发生在相同事务中的不同组件之间是彼此独立的， 而每个组件都会请求同样的数据。我们并不清楚当前上下文中已经加载了哪些数据，最 后只得多次发出同样的查询。 发出多个查询语句以获得某一数据集。通常这是由于没有充分利用到复杂的SQL 语句、 存储过程等在一次批处理中获取需要的数据所导致的。
问题二：过多地使用同步
同步对于应用中共享数据的保护来说是至关重要的举措。在高负载或是产品环境下过度使用
同步（如在超大段代码中使用同步）会导致严重的性能与可伸缩性问题。
问题三：过度使用远程调用
很多库都使用了远程通信。每一次远程调用都会涉及到延迟、序列化、网络堵塞以及内存使用
等问题。如果没有经过深思熟虑而盲目使用这些远程技术就会导致严重的性能与可伸缩性问题。
问题四：错误地使用对象关系映射
对象关系映射为开发者解决了很多负担，比如从数据库中加载对象以及将对象持久化到数据库
中。但对象关系映射有很多配置选项需要优化，错误的配置与不正确的使用都会导致始料不及的性能
问题。在使用对象关系映射框架前，请务必保证熟悉所有的配置，如果有机会，请深入到所用框架的
内核，这样使用起来才有保障。
问题五：内存泄漏
托管的运行时环境（如Java 和.NET）可以通过垃圾收集器进行内存管理。但垃圾收集器无法 避免内存泄漏问题。“被遗忘”的对象依旧会占据着内存，最终将会导致内存泄漏问题。当对 象不再需要时，请尽快释放掉对象引用。
问题六：使用有问题的第三方代码/组件
没有人会从头编写应用的全部功能。我们都会使用第三方程序库来加快开发进程。这么做不 仅会加速产出，也增加了性能上的风险。虽然大多数框架都具有良好的文档并且经过了充分 的测试，但没人能够保证这些框架在任何时候都会像预期的那样好。因此，在使用这些第三 方框架时，事先一定要做好充分的调研。 问题七：对稀缺资源的使用存在浪费的情况
内存、CPU、I/O 以及数据库等资源属于稀缺资源。在使用这些资源时如果存在浪费的情况 就会造成严重的性能与可伸缩性问题。比如说，有人会长时间打开数据库连接而不关闭。连 接应该只在需要的时候才使用，使用完毕后就应该放回到连接池中。我们经常看到有人在请 求一开始就去获取连接，直到最后才释放，这么做会导致性能瓶颈。
问题八：膨胀的Web 前端 由于现在的 Web 速度越来越快，用户的网络体验也越来越好。在这个趋势下，很多应用的 前端都提供了太多的内容，但这么做会导致差劲的浏览体验。很多图片都太大了，没有利用 好或是错误地使用了浏览器缓存、过度地使用JavaScript/AJAX 等，所有这一切都会导致浏览 器的性能问题。
问题九：错误的缓存策略导致过度的垃圾收集
将对象缓存在内存中可以避免每次都向数据库发出请求，这么做可以提升性能。但如果缓存 了太多的对象，或是缓存了很多不常使用的对象则会将缓存的这种优势变成劣势，因为这会 导致过高的内存使用率及过多的垃圾收集活动。在实现缓存策略前，请想好哪些对象需要缓 存，哪些对象不需要缓存，进而避免这类性能与可伸缩性问题。
问题十：间歇性问题
间歇性问题很难发现。通常这类问题与特定的输入参数有关，或是发生在某个负载条件下。 完全的测试覆盖率及负载与性能测试能在这些问题产生前就发现他们。
问题十一：尽量减少http连接数
减少单个PV的http连接数，肯定可以增加单台服务器的用户负载数。减少Http连接数的具体
方法是减少没必要的iframe使用，合并js文件，css文件，和一种常见的方法---合并Css小背景图
（图片都被合并成了一张大图，然后用Css的Background-positioin属性控制显示背景图片的位置）
通过css控制在页面上单独显示每一个小图。这样每一个用户访问就相当于减少了n-1个http连接数，
这对于访问量大的网站来说，吞吐量的提升是显而易见的。
…………