| 这里主要讨论故障分析内容以及优化调整设置内容，同时还与读者分享故障分析的经验与实例。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 交易的响应时间如果很长，远远超过系统性能的需求，表示耗费CPU的数据库操作。例如排序，执行aggregate functions（例如sum、min、max、count）等较多，可考虑是否有索引以及索引建立得是否合理。尽量使用简单的表链接、水平分割大表格等方法来降低该值。
|
|
|
|
|
| 测试工具可以模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器，这样，就可以在Web端测出的响应时间减去以上各个分段测出的时间，就可以知道瓶颈在哪里并着手调优。
|
|
|
|
|
| UNIX资源监控（NT操作系统同理）中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈，也可能是内存访问命中率低。“Swap in rate”和“Swap out rate”也有类似的解释。
|
|
|
|
|
| UNIX资源监控（NT操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。合理使用的范围在60%～70%。
|
|
|
|
|
| Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5～2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
|
|
|
|
|
| SQL Server资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。
|
|
|
|
|
| 针对上述故障分析的重点内容，需要做相应的优化调整，建议如下。
|
|
|
|
|
|
|
|
|
| ③考虑在其他体系上设计系统，例如增加前置机、设置并行服务器等。
|
|
|
|
|
| ①内存的优化包括操作系统、数据库、应用程序的内存优化；
|
|
|
|
|
|
|
|
|
| ⑤调整数据块缓冲区大小（用数据块的个数表示）是一个重要内容；
|
|
|
|
|
|
|
| ①磁盘读写进度对数据库系统是至关重要的，数据库对象在物理设备上的合理分布能改善性能。
|
|
|
|
|
| ③通过把日志和数据库对象分布在独立的设备上，可以提高系统的性能。
|
|
|
| ④把不同的数据库放在不同的硬盘上，可以提高读写速度。建议把数据库、回滚段、日志放在不同的设备上。
|
|
|
| ⑤把表放在一块硬盘上，把非簇的索引放在另一块硬盘上，保证物理读写更快。
|
|
|
|
|
|
|
| ②并行操作资源限制的参数（并发用户的数目、会话数）。
|
|
|
|
|
|
|
|
|
| ①可以通过数组接口来减少网络呼叫。不是一次提取一行，而是在单个往来往返中提取10行，这样做效率较高。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 当在合理的加载下出现这些类型的问题时，则表示可能有基础性的设计问题，比如说：算法问题，低效的数据库应用程序交互作用等，这些都不是通过简单升级硬件以及调整系统配置就可以解决的问题，此时软件的故障定位和调优将占有更重要的地位。
|
|
|
|
|
| 目前Web开发者开始提供可定制的Web网站，例如，像搜索数据之类的任务，现在可以由服务器执行，而无需客户干预。然而，这些变革也导致了一个结果，这就是许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。
|
|
|
|
|
|
|
|
|
|
|
|
|
| 优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。
|
|
|
| 这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预先从数据库提取信息，写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的生成。
|
|
|
| 当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。
|
|
|
| 每当该页面被调用时，脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值，更新脚本就会运行，否则，该ASP页面把余下的HTML代码发送给浏览器。
|
|
|
| 如果每次访问ASP页面的时候都要提供最新的信息，或者输出与用户输入密切相关，这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。
|
|
|
| 如果数据库内容由客户通过适当的ASP页面更新，要确保静态页面也能够自动反映数据的变化，我们可以在ASP页面中调用Update脚本。这样，每当数据库内容改变时，服务器上也有了最新的静态HTML页面。
|
|
|
| 另一种处理频繁变动数据的办法是借助Microsoft SQL Server 7.0或以上版本的Web助手向导（Web Assistant Wizard），这个向导能够利用Transact-SQL、存储过程等从SQL Server数据生成标准的HTML文件。
|
|
|
| Web助手向导能够用来定期地生成HTML页面。正如前面概要介绍的方案，Web助手可以通过触发子更新HTML页面，比如在指定的时间执行更新或者在数据库数据变化时执行更新。
|
|
|
| SQL Server使用名为sp_makewebtask的存储过程创建HTML页面，它的参数是目标HTML文件的名字和待执行存储过程的名字，查询的输出发送到HTML页面。另外，也可以选择使用可供结果数据插入的模板文件。
|
|
|
| 万一用户访问页面的时候正好在执行更新，我们可以利用锁或者其他类似的机制把页面延迟几秒钟。
|
|
|
| 我们对纯HTML加调度ASP代码和普通的ASP文件进行了性能测试。普通的ASP文件要查找5个不同的表为页面提取数据。为了和这两个文件相比较，对一个只访问单个表的ASP页面和一个纯HTML文件也进行了测试。测试结果如下表所示。
|
|
|
|
|
|
|
| 其中TTFB是指“Total Time to First Byte”, TTLB是指“Total Time to Last Byte”。
|
|
|
| 测试结果显示，访问单个表的ASP页面的处理时间是720.5ms，而纯HTML文件则为427ms。普通的ASP文件和纯HTML加调度ASP代码的输出时间相同，但它们的处理时间分别为3633.67ms和1590ms。也就是说，在这个测试环境下我们可以把处理速度提高43%。
|
|
|
| 如果我们要让页面每隔一定的访问次数进行更新，比如100次，那么这第100个用户就必须等待新的HTML页面生成。不过，这个代价或许不算太高，其他99个用户获得了好处。
|
|
|
| 静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。
|
|
|
| 在大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能，而且无须在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能，但也有许多网站完全由于进行大量没有必要的数据库调用，而表现出很差的性能。
|
|
|
