做网站用 jsp还是asp,深圳企业建站程序,企业微信公众平台开发,做门户网站需要什么资质在上一篇文章中我们使用了几种方法来确定瓶颈#xff0c;找到瓶颈#xff0c;下面再回顾一下#xff1a; LoadRunner压力测试Windows计数器#xff0c;这种方法主要是找出大概的性能问题是在哪台服务器#xff0c;主要是哪个资源紧张。 ANTS ProfilerSQL Server Profiler找到瓶颈下面再回顾一下 LoadRunner压力测试Windows计数器这种方法主要是找出大概的性能问题是在哪台服务器主要是哪个资源紧张。 ANTS ProfilerSQL Server Profiler这两个工具的完美搭配可以准确的定位性能是出在哪个函数哪个SQL语句上。如果性能问题是出在程序上那么就要根据业务对程序中的函数进行调整可能是函数中的写法有问题算法有问题这种调整如果不能解决问题的话那么就要从架构上进行考虑我们是不是应该使用这种技术有没有替代的方案来实现同样的业务功能举个简单的例子假设经过跟踪发现一个负责生成图表的函数存在性能问题尤其是在压力测试情况下性能问题尤为严重。原来的图表生成是完全基于GDI在Web服务器上根据数据进行复杂的绘图然后将绘出的图片保存在磁盘上然后在HTML中添加Img标签来引用图片的地址。现在使用GDI会消耗大量内存和CPU而算法上也没有太大的问题那么这种情况下我们就需要考虑修改架构不使用GDI 绘图的方式或者是使用异步绘图的方式。既然绘图会消耗大量的服务器资源那么一种解决办法就是将绘图的操作从服务器转移到客户端。使用SilverLight技术在用户打开网页是只是下载了一个SilverLight文件该文件负责调用Web服务器的Web服务将绘图所需的数据获取下来然后在客户端绘图展现出来。这样服务器只提供WebService的数据访问接口不需要做绘图操作。 .net上的优化我暂时不表今天主要讲数据库的优化。使用ANTS ProfilerSQL Server Profiler我们可以精确定位某个业务操作对应的数据库脚本或者存储过程。ANTS Profiler告诉我们一个方法在调用的时候花了10秒的时间那么我们就可以使用VS打开源代码找到该放入然后找到对应调用的存储过程这里也许一个方法里面调用了多个数据层方法调用了多个存储过程。将调用的这些存储过程记下了然后在SQL Server Provider的跟踪文件里面去找调用该存储过程花费的Duration。 ANTS Provider跟踪出调用该方法的时间-SUM(所有调用的存储过程的Duration)C#中进行逻辑处理的时间Web服务器和数据库服务器之间网络传输数据的时间 一般企业应用或小型应用中数据库服务器和Web服务器要不是就在同一个机房同一个局域网或者干脆是同一台机器这种情况下网络传输速度是很快的所以我们不考虑网络传送上面的时间。那么就得出 C#中进行逻辑处理的时间ANTS Provider跟踪出调用该方法的时间-SUM(所有调用的存储过程的Duration) 代码中的时间得到了SQL Server中的时间也就是Duration字段得到了那么就可以判断出打开该页面各个服务器所花费的时间从而找到我们要优化的方向是存储过程还是C#代码。如果是存储过程那么通过查询SQL Server Profiler中内容可以找到具体是哪一个存储过程消耗的时间最长。 “射人先射马擒贼先擒王。”多个存储过程被调用如果性能出在数据库服务器上那么进行性能优化时首先要调优的是最大Duration最大的存储过程另外还有就是Reads很大的存储过程。如果Duration很大但是Reads和Writes都不算特别大那么有可能是以下原因 这个存储过程相关的资源正在被其他事务占用也就是说该存储过程被阻塞所以才花了那么多时间。这种情况只需要把该存储过程提出多执行几次看是不是仍然Duration很大但Reads不大。 存储过程本身很复杂里面的T-SQL语句就是五六百行编译出的执行计划也是一堆里面进行了大量的逻辑判断、大量函数的调用这种情况下进行调优就比较痛苦了。实际上这次我调优的这个项目就是如此抓取出来的存储过程尽是复杂的逻辑少则两三百行代码多则五六百行里面还有大量的用户定义函数的调用。对于这种存储过程我接下来会专门写篇博客介绍下我们这个项目是如何调优的。 程序读取的数据不多但是需要对数据进行大量的运算。哈希联接、聚合函数、DISTINCT、UNION等都是比较耗CPU的。如果是这种情况那就看能不能建立索引或者改写法进行调优。前面说的是Duration大而Reads小的情况当然更常见的情况是Duration和Reads都很大。那么我们就将主要精力集中在如何减小Reads上。造成Reads很多的原因大概有以下几种 没有建立相应的索引。对表t1进行查询条件是where c2abc返回c1,c2,c3三个字段那么这种情况下如果没有对c2建立非聚集索引c1是主键建立了聚集索引那么这个查询将会进行“聚集索引扫描”本来可能只查出几条记录的结果要把表的所有记录都扫描一篇自然Reads就高了。解决办法就是建立相应的索引比如这里只需要对c2字段建立非聚集索引然后将c3字段作为包行列就行了。如果只是最c2字段建立非聚集索引那么前面说到的查找在进行了“非聚集索引查找”后还会进行“键查找”来找到c3列的值所以要建立的正确的索引才行。 不符合SARG原则。查询如果不符合SARG原则那么即使建立了索引也没法使用。SARG就是查询参数的意思具体怎么写才符合SARG大家可以百度已经有很多相关文章了我就不累述。 涉及的业务数据量大。也就是说即使建立了正确的索引查询也符合SARG使用到了该索引但是由于涉及的数据量太大了所以Reads仍然很大。这种情况就不能再从索引和查询入手而只能从数据库的设计入手。是否能够增加适当的冗余字段对数据库进行反范式化或者如果数据的实时性要求不高的话则可以建立中间汇总表使用SQL作业来维护这个中间汇总表查询的时候只查询该中间汇总表即可。或者是否可以建立索引视图或者计算列然后在计算列中建立索引的方式进行一个预运算减小实际查询时涉及的数据量。 使用了不当的视图。如果对视图的定义很复杂涉及的表很多在查询的时候使用了该视图但是实际上只用到了视图中的一张或两张表对视图的查询会造成系统根据视图定义查询其他与该查询不相关的表。所以在使用视图的时候一定要知道视图的定义不用贪图一时的方便而随便使用视图。 不正确的使用了用户定义函数。一个存储过程中几百行代码出于编写方便大量的调用了一个用户定义表值函数而该函数是进行了复杂的查询和运算才返回结果的。如果数次或者数十次的调用该用户定义表值函数那么就会进行很多这种复杂的查询和运算自然Reads也就很大了。解决办法是尽量减少对这种复制函数的调用比如一次调用后就将解决保存在表变量或临时表中接下来再使用的话就使用该表变量或临时表即可。如果Duration并不大但是Reads却很大的查询仍然需要需要进行优化。虽然表现出来消耗的时间并不大但是由于Reads很多那么说明要进行大量的IO在高并发的情况下大量的IO处理不过来会加重磁盘的负担造成CPU占用率上升性能降低这时其Duration就会变大。关于Duration不大但是Reads很大的情况仍然是前面说到的几点情况建立相关索引、修改查询语句等便可解决。转载于:https://www.cnblogs.com/studyzy/archive/2008/11/24/1339772.html
