应用程序优化
本文只从逻辑上进行说明,并不从物理上进行说明。物理结构不在本文讨论范围之内。
我们的资源有:CPU,内存,IO
我们的应用程序分以下三层:表现层,业务逻辑层,数据操作层
优化其实是对以上所说的进行优化。优化前必须明确以下几点:原有的应用程序设计不能受到破坏;原有的需求不得更改;应用程序的可维性不得降低。至于为什么,刚才写的草稿说了,没有保存,懒得再写。原因大家也知道,感觉写了会浪费
。直接进入主题:分为数据库问题与应用程序问题。
假设数据库出现问题,这个时候我们知道用户在进行什么样的操作。打开SQL监视器,进行用户操作,然后在SQL监视器里面定位问题所在。SQL问题所在分为SQL语句以及这条语句里面对资源所产生的消耗。把SQL语句拿到SQL管理器进行查询分析,这样你就能定位到语句中什么地方产生问题,然后对表结构(聚集索引以及非聚集索引)以及SQL语句进行调整。简单吧,而事实上就是这么简单的。
假设应用程序出现问题,这个时候我们同样也知道用户在进行什么样的操作。问题是在于有没有工具能监视到所在的代码行。有的,05以及其后的版本据我所知是有的。另外推荐另外一个工具:ants profile。使用这个工具外加一个并发仿真模拟就能很快找到问题所在。另外你还可以使用性能计数器(这个只能查到到一些,但不能真正定位)。
看完了以上所说,你可能会问,优化咋这么简单呢??????????而事实上就是这么简单的,难道真的不好用吗????而事实上简单是最好用,最实用的。
在这里我在网上看了很多优化的文章,感觉写的非常详细具体,也非常不错,只不过没有说明如何定位问题的所在。但是在商业环境下并不适合,因为商业环境下是需要以最低的成本创造出最高的商业价值。从一大堆代码去慢慢找吧,累死人,而并未能解决问题所在。而从商业价值的角度上看,这无疑是个失败的。为什么呢???????原因很简单,他们并没有快速找出问题对象的所在,并且迅速的解决问题。我的观点是:快速把主要问题解决了,大家去喝茶,聊天,学技术,不要把时间用在一些小点子上,从结构上的优化性能远高于每一行代码优化的性能,不要最后在性能问题上搞得上面郁闷,下面更加郁闷。