系统性能调优技术实战分享

本文目录如下：

1、概述

1、1 系统性能定义

1、2 目的意义

2、性能优化技术

2、1 前端优化

2、2 后端优化

3、总结

1、概述

最近看了很多关于系统性能调优的文章，发现很多文章都是介绍某一方面的，例如专门数据库方面的优化、前端页面的优化等等都不是很全面，这里结合我在工作中的一些实践对系统性能调优技术来一个综合性的分享。

1、1 系统性能定义

优化实战

下面举例来说明DBCC SHOWCONTIG和DBCC REDBINDEX的使用方法。以应用程序中的Employee数据表作为例子，在 SQL Server的Query analyzer输入命令：
use database_name
declare @table_id int
set @table_id=object_id('Employee')
dbcc showcontig(@table_id)

输出结果：
DBCC SHOWCONTIG scanning 'Employee' table...
Table: 'Employee' (1195151303); index ID: 1, database ID: 53
TABLE level scan performed.
- Pages Scanned................................: 179
- Extents Scanned..............................: 24
- Extent Switches..............................: 24
- Avg. Pages per Extent........................: 7.5
- Scan Density [Best Count:Actual Count].......: 92.00% [23:25]
- Logical Scan Fragmentation ..................: 0.56%
- Extent Scan Fragmentation ...................: 12.50%
- Avg. Bytes Free per Page.....................: 552.3
- Avg. Page Density (full).....................: 93.18%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
通过分析这些结果可以知道该表的索引是否需要重构。如下描述了每一行的意义：
信息                                           描述
Pages Scanned                    表或索引中的长页数
Extents Scanned                 表或索引中的长区页数
Extent Switches                  DBCC遍历页时从一个区域到另一个区域的次数
Avg. Pages per Extent         相关区域中的页数
Scan Density[Best Count:Actual Count]
Best Count是连续链接时的理想区域改变数，Actual Count是实际区域改变数，Scan Density为100%表示没有分块。
Logical Scan Fragmentation   扫描索引页中失序页的百分比
Extent Scan Fragmentation    不实际相邻和包含链路中所有链接页的区域数
Avg. Bytes Free per Page       扫描页面中平均自由字节数
Avg. Page Density (full)         平均页密度，表示页有多满

从上面命令的执行结果可以看的出来，Best count为23 而Actual Count为25这表明orders表有分块需要重构表索引。下面通过DBCC DBREINDEX来重构表的簇索引。

3. DBCC DBREINDEX 用法
重建指定数据库中表的一个或多个索引。

语法
DBCC DBREINDEX
(    [ 'database.owner.table_name'
[ , index_name
[ , fillfactor ]
]
]
)

参数
'database.owner.table_name'
是要重建其指定的索引的表名。数据库、所有者和表名必须符合标识符的规则。有关更多信息，请参见使用标识符。如果提供 database 或 owner 部分，则必须使用单引号 (') 将整个 database.owner.table_name 括起来。如果只指定 table_name，则不需要单引号。

index_name
是要重建的索引名。索引名必须符合标识符的规则。如果未指定 index_name 或指定为 ' '，就要对表的所有索引进行重建。

fillfactor
是创建索引时每个索引页上要用于存储数据的空间百分比。fillfactor 替换起始填充因子以作为索引或任何其它重建的非聚集索引（因为已重建聚集索引）的新默认值。如果 fillfactor 为 0，DBCC DBREINDEX 在创建索引时将使用指定的起始 fillfactor。

同样在Query Analyzer中输入命令：
dbcc dbreindex('database_name.dbo.Employee','',90)

然后再用DBCC SHOWCONTIG查看重构索引后的结果：
DBCC SHOWCONTIG scanning 'Employee' table...
Table: 'Employee' (1195151303); index ID: 1, database ID: 53
TABLE level scan performed.
- Pages Scanned................................: 178
- Extents Scanned..............................: 23
- Extent Switches..............................: 22
- Avg. Pages per Extent........................: 7.7
- Scan Density [Best Count:Actual Count].......: 100.00% [23:23]
- Logical Scan Fragmentation ..................: 0.00%
- Extent Scan Fragmentation ...................: 0.00%
- Avg. Bytes Free per Page.....................: 509.5
- Avg. Page Density (full).....................: 93.70%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
通过结果我们可以看到Scan Denity为100%。

2.1.5 静态化

静态化一些不常变的页面和数据，并gzip一下。使用nginx的sendfile功能可以让这些静态文件直接在内核心态交换，可以极大增加性能。

一般我们可以做一个静态文件管理功能，可以把我们网站的一些栏目直接通过请求/响应的方式在服务器上直接生成静态文件，当然这里可以设置一个时间频率，用户直接访问静态页面访问效率肯定非常高！

2.1.6 缓存

通常，应用程序可以将那些频繁访问的数据，以及那些需要大量处理时间来创建的数据存储在内存中，从而提高性能;它包括应用程序缓存和页输出缓存；

一般我们大部分用的是应用程序缓存

缓存的应用场景主要有：



OutputCache

我们可以用Fiddler找出一些内容几乎不会改变的页面，给它们设置OutputCache指令即可；

对于设置过OutputCache的页面来说，浏览器在收到这类页面的响应后，会将页面响应内容缓存起来。 只要在指定的缓存时间之内，且用户没有强制刷新的操作，那么就根本不会再次请求服务端， 而对于来自其它的浏览器发起的请求，如果缓存页已生成，那么就可以直接从缓存中响应请求，加快响应速度。 因此，OutputCache指令对于性能优化来说，是很有意义的（除非所有页面页面都在频繁更新）。

应用程序缓存

应用程序缓存提供了一种编程方式，可通过键/值对将任意数据存储在内存中，这里提供一个asp.net对缓存有效封装的例子，见缓存机制理解及C#开发使用。

缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：

1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。

2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。

3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，所以，缓存的持久化也是需要考虑的。