领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
服务器端编程的十大性能问题
作者 张龙 发布于 2010年8月27日
今年5月底，瑞士计算机世界杂志上刊登了Web性能诊断专家Bernd Greifeneder的一篇文章，文章列举了其在过去几年工作中所遇到的服务器端编程的十大性能问题。Andreas Grabner则在自己的博客上对这些性能问题给出了进一步阅读的链接。希望这些问题与相关的延伸阅读能为广大的InfoQ读者带来一定的启示。
问题一：过多的数据库调用
我们发现经常出现的一个问题就是在每次请求/事务中存在过多的数据库查询。有如下三个场景作为佐证：
- 在一次事务上下文中所请求的数据比实际需要的数据多出很多。比如说：请求所有的账户信息而不是仅仅查询出当前需要显示的信息。
- 多次请求同样的数据。这种情况通常发生在相同事务中的不同组件之间是彼此独立的，而每个组件都会请求同样的数据。我们并不清楚当前上下文中已经加载了哪些数据，最后只得多次发出同样的查询。
- 发出多个查询语句以获得某一数据集。通常这是由于没有充分利用到复杂的SQL语句、存储过程等在一次批处理中获取需要的数据所导致的。
延伸阅读：Blog on Linq2Sql Performance Issues on Database、Video on Performance Anti-Patterns
问题二：过多地使用同步
毫无疑问，同步对于应用中共享数据的保护来说是至关重要的举措。但有很多开发者却过度使用同步，比如在超大段的代码中使用同步。在低负载的情况下，这么做倒没什么问题；但在高负载或是产品环境下，过度的同步会导致严重的性能与可伸缩性问题。
延伸阅读： How to identify synchronization problems under load
问题三：过度使用远程调用
很多库都使用了远程通信。对于开发者来说，远程调用与本地调用似乎没什么区别，但如果不清楚远程调用的本质就会铸成大错，因为每一次远程调用都会涉及到延迟、序列化、网络堵塞以及内存使用等问题。如果没有经过深思熟虑而盲目使用这些远程技术就会导致严重的性能与可伸缩性问题。
延伸阅读： Performance Considerations in Distributed Applications
问题四：错误地使用对象关系映射
对象关系映射为开发者解决了很多负担，比如从数据库中加载对象以及将对象持久化到数据库中。但与其他任何框架一样，对象关系映射也有很多配置选项需要优化，只有这样才能适应于当前应用的需要。错误的配置与不正确的使用都会导致始料不及的性能问题。在使用对象关系映射框架前，请务必保证熟悉所有的配置，如果有机会，请深入到所用框架的内核，这样使用起来才有保障。
延伸阅读：Understanding Hibernate Session Cache、Understanding the Query Cache、Understanding the Second Level Cache
问题五：内存泄漏
托管的运行时环境（如Java和.NET）可以通过垃圾收集器进行内存管理。但垃圾收集器无法避免内存泄漏问题。“被遗忘”的对象依旧会占据着内存，最终将会导致内存泄漏问题。当对象不再需要时，请尽快释放掉对象引用。
延伸阅读：Understanding and finding Memory Leaks
问题六：使用有问题的第三方代码/组件
没有人会从头编写应用的全部功能。我们都会使用第三方程序库来加快开发进程。这么做不仅会加速产出，也增加了性能上的风险。虽然大多数框架都具有良好的文档并且经过了充分的测试，但没人能够保证这些框架在任何时候都会像预期的那样好。因此，在使用这些第三方框架时，事先一定要做好充分的调研。
延伸阅读： Top SharePoint Performance Mistakes
问题七：对稀缺资源的使用存在浪费的情况
内存、CPU、I/O以及数据库等资源属于稀缺资源。在使用这些资源时如果存在浪费的情况就会造成严重的性能与可伸缩性问题。比如说，有人会长时间打开数据库连接而不关闭。连接应该只在需要的时候才使用，使用完毕后就应该放回到连接池中。我们经常看到有人在请求一开始就去获取连接，直到最后才释放，这么做会导致性能瓶颈。
延伸阅读： Resource Leak detection in .NET Applications
问题八：膨胀的Web前端
由于现在的Web速度越来越快，用户的网络体验也越来越好。在这个趋势下，很多应用的前端都提供了太多的内容，但这么做会导致差劲的浏览体验。很多图片都太大了，没有利用好或是错误地使用了浏览器缓存、过度地使用JavaScript/AJAX等，所有这一切都会导致浏览器的性能问题。
延伸阅读： How Better Caching would help speed up Frankfurt Airport Web Site、Best Practices on Web Performance Optimization
问题九：错误的缓存策略导致过度的垃圾收集
将对象缓存在内存中可以避免每次都向数据库发出请求，这么做可以提升性能。但如果缓存了太多的对象，或是缓存了很多不常使用的对象则会将缓存的这种优势变成劣势，因为这会导致过高的内存使用率及过多的垃圾收集活动。在实现缓存策略前，请想好哪些对象需要缓存，哪些对象不需要缓存，进而避免这类性能与可伸缩性问题。
延伸阅读：Java Memory Problems、Identify GC Bottlenecks in Distributed Applications
问题十：间歇性问题
间歇性问题很难发现。通常这类问题与特定的输入参数有关，或是发生在某个负载条件下。完全的测试覆盖率及负载与性能测试能在这些问题产生前就发现他们。
延伸阅读：Tracing Intermittent Errors by Lucy Monahan from Novell、How to find invisible performance problems
张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。
复杂的SQL语句和存储过程一次性获取数据不可取
发表人
chen Rex
发表于
Re: 复杂的SQL语句和存储过程一次性获取数据不可取
发表人
张 龙
发表于
Re: 复杂的SQL语句和存储过程一次性获取数据不可取
发表人
chen Rex
发表于
Re: 复杂的SQL语句和存储过程一次性获取数据不可取
发表人
wang shaoying
发表于
Re: 复杂的SQL语句和存储过程一次性获取数据不可取
发表人
Guo Shilai
发表于
过多的使用JS和Ajax
发表人
liangjun zheng
发表于
Re: 过多的使用JS和Ajax
发表人
Huangfu Fanfeng
发表于
Re: 过多的使用JS和Ajax
发表人
Guo Shilai
发表于
-
文中：发出多个查询语句以获得某一数据集。通常这是由于没有充分利用到复杂的SQL语句、存储过程等在一次批处理中获取需要的数据所导致的。
这句话很明显有问题，复杂的SQL语句和存储过程确实可以一次搞定需要的数据，但却失去了数据的可缓存性，通常返回的数据有很多都是可缓存的，如果使用一条SQL或者存储过程完成，那就使不常变数据和经常变的数据粘合到一起，导致不常改变的数据无法进行相应的缓存，这是不可取的。 -
js和服务端没关系吧？就算js写的不好那也是用户体验的问题
ajax也可以利用缓存 也不会对服务端造成压力，不该缓存的地方，用啥都不能缓存 -
为何说使用复杂sql或是过程所得到的数据就没办法缓存呢？作者文中的意思是本来可以通过一定的sql语句一次性查询到所需的数据，但人们有时却使用多条简单的sql语句发出多次查询以得到需要的数据，这种情况是需要避免的。
-
JS和Ajax是客户端编程，而作者讲的是服务器端编程，缓存问题也是在讨论服务器端缓存，所以JS和Ajax的缓存问题不是本文要讨论的范围。
-
比如一个用户信息表，一个是用户评论表，你的页面要显示用户信息和评论，如果按照一条SQL搞定，由于评论会经常更改，所以为了保障实时性，评论不进行缓存，如果你用一条SQL的话，那就是说你每次显示这个页面都需要进行SQL查询两张关联表，但是如果你分开进行，那么查询用户信息的SQL基本上在更新前只需要查询一次，而每次访问页面，只需要查一个评论表即可，你说哪个性能更高呢？这只是个简单的例子，在现实中还有更多更复杂的情况，性能损耗将更加严重，将数据进行这种区分是有必要的，一条SQL查出所有的数据并不可取。
-
确实有点片面
-
无疑是增加了请求数
-
支持你的观点，一次搞定所有数据并不可取，应根据变动频繁程度来区分数据，并应用适当的缓存策略可以达到预想不到的效果，否则你会发现，你的性能问题就是因为一条SQL导致的，因为它过于复杂和效率低下。
8 条回复
关注此讨论 回复