软件性能调优
最近一直在忙乎产品的性能问题，包括支持大数据量和提高并发数，为此还专门成立了一个性能研究小组，软件的性能调优真的很棘手，需要太多太多的积累，软件越是庞大挑战程度越高，目前我们正在做的产品代码行数已经有500K，前后共经手约50人，巅峰阶段有30人的研发团队，其中包括很多刚毕业的新新人，再加上产品架构支持2个很重要的属性：多语言 & 多数据库，性能调整难度可想而知。
目前QA Team测出来的平均并发量是50，核心基础数据10K，离高端客户群的正常应用差距较大，目前表现最明显的有2点：A、Web服务器CPU占用过高；B、DB Server 死锁进程持续增长。对于第二点我们的某个客户IT总监举了一个很形象的例子：系统就像公交车绕城持续运作，自生最大承载量是50，如果每个站台都是自由上下车，那么可以支持几倍的人员乘车，但是我们的系统就如同有部分人员一直不下车，并且这部分人持续增加，最后公交车就开不动了。。。当然我给他的短期答复也很简单：找个人在车上，如果有1小时以上未下车的人直接强行销毁
产品的修改思路其实也不复杂(主要是工作量大)，大概分几个方面：
1、减少不必要的事务，降低事务的锁表时间
2、SQL调优，索引调优
4、代码优化，统一使用标准
3、业务优化
希望这次能把性能问题尽快调整到一个可接受的程度，路漫漫其修远兮，偶们上下而求索~~~~~~
目前QA Team测出来的平均并发量是50，核心基础数据10K，离高端客户群的正常应用差距较大，目前表现最明显的有2点：A、Web服务器CPU占用过高；B、DB Server 死锁进程持续增长。对于第二点我们的某个客户IT总监举了一个很形象的例子：系统就像公交车绕城持续运作，自生最大承载量是50，如果每个站台都是自由上下车，那么可以支持几倍的人员乘车，但是我们的系统就如同有部分人员一直不下车，并且这部分人持续增加，最后公交车就开不动了。。。当然我给他的短期答复也很简单：找个人在车上，如果有1小时以上未下车的人直接强行销毁
产品的修改思路其实也不复杂(主要是工作量大)，大概分几个方面：
1、减少不必要的事务，降低事务的锁表时间
2、SQL调优，索引调优
4、代码优化，统一使用标准
3、业务优化
希望这次能把性能问题尽快调整到一个可接受的程度，路漫漫其修远兮，偶们上下而求索~~~~~~
