最近公司为客户新上线了一个系统，主要做为日常办公之用。试用两天后，客户反映系统速度很慢，主要表现为首页面加载速度慢。下图为首页概况：
这是一个老日常办公系统的增强版，所以页面虽然是新的，但页面与数据大部份都是旧的。首页只是个大框架，然后把原系统的各个部份做成单独的页面放入进来。其中菜单部份用iframe套了老系统的菜单，任务列表通过访问原系统的web services获取数据，工作区是个tab页，第一个tab页是一些信息公告，用了近十个iframe来套老系统的页面。
我们系统大量采用了ajax，在页面还没有加载出来的时候，其空白处就显示："加载中..." 。客户反映，主要是ie6用户，有时候首页上满页面都是加载中...要等近10秒才能显示出来。
我的第一个返映就是：是不是因为ie6的js引擎效率低导致的，通过用httpwatch观查，发现其更重要的原因是http请求比较多，且系统返回数据时间较长，造成了很严重的排队现象。这就要从两个方面来解决了：服务端与客户端。
首先是客户端。ie6不仅js引擎效率低，且对于同一服务器只能有两个并发解求，当http请求较多的时候，页面加载速度慢的问题就特别明显。解决方法是下载MS的一个ie补丁，它可以将ie6/ie7的最大连接数由2个改为10个。
服务端分为web服务器与数据库服务器。我首先查看了Web服务器：一个16核11G内存万转硬盘的怪物。 发现基本没有负载！！！CPU的使用率在1%以下！NB啊。然后去查看了数据库服务器，果真，问题出在这里！
由于是生产环境，sql server 是不能用D版滴。客户为了节约预算，将这个新系统的数据库与别的一些系统的数据库放到了一台机器上。结果我今天去看的时候，发现虽然内存与硬盘负载曲线都比较低且稳定，但CPU的负载却长期70%以上，有时达到100%的时间长达几秒钟！CUP成了整个系统最大的瓶颈！解决的方法很简单，我们找了另外一台现有的且负载较低的数据库服务器，将数据库移过去就行了！
问题到这里并没有结束。为什么CUP的负载这么大？据我所知除了这个新系统的数据库，机子上就只有另外一个系统的数据库。且即使把这个新系统移走后，CPU的负载仍没有明显的改观，长期60%到80%，且这是下午了，根本不是系统最繁忙的时候。我在网上找了找资料，然后打开windows的性能监视器，并加入指定计数器进行观查，发现最大的问题在于数据库的整表扫描过多！网上说这个监控数最好不要超过2，但是这个系统长期100+到200+，且动不动就死锁一下，难怪CPU的负载高，都去做这事了~~~
以下是我总结的常见的sqlserver 性能计数器
|
指标描述 |
指标范围 |
指标单位 |
|
|
SQL Server中访问方法（ Access Methods） |
|||
|
全表扫描 /秒 ( Full Scans/sec) |
指 每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间，因此全表扫描的频率过高的话，会影响性能。 |
如果该指标的值比 1或 2 高，应该分析设计的查询以确定是否确实需要全表扫描，以及 SQL 查询是否可以被优化。 |
次数 /秒 |
|
Page splits/sec |
由于数据更新操作引起的每秒页分割的数量。 |
||
|
SQL Server中缓冲器管理器（ Buffer Manager） |
|||
|
缓冲区高速缓存命中率 (Buffer Cache Hit Ratio % ） |
指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比。该比率是缓存命中总次数与缓存查找总次数之比。经过很长时间后，该比率的变化很小。由于从缓存中读取数据比从磁盘中读取数据的开销小得多，一般希望该比率高一些。 |
该指标的值最好为 90% 或更高。通常可以通过增加 SQL Server 可用的内存数量来提高该指标的值。增加内存直到这指标的值持续高于 90%，表示 90% 以上的数据请求可以从数据缓冲区中获得所需数据。 |
% |
|
读的页 /秒 ( Page Reads/sec) |
指每秒发出的物理数据库页读取数。该指标主要考察数据库从磁盘读取数据的频率。因为物理 I/O 会耗费大量时间，所以应尽可能地减少物理 I/O 以提高性能。 |
该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，以降低该指标的值。 |
个数 /秒 |
|
写的页 /秒 ( Page Writes/sec) |
指每秒执行的物理数据库写的页数。该指标主要考察数据库向磁盘写入数据的频率。因为物理 I/O 会耗费大量时间，所以应尽可能地减少物理 I/O 以提高性能。 |
该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，以降低该指标的值。 |
个数 /秒 |
|
惰性写 /秒 ( Lazy Writes/sec) |
指每秒被缓冲区管理器的惰性编写器写入的缓冲区数。惰性编写器是一个系统进程，用于成批刷新脏的老化的缓冲区（包含更改的缓冲区，必须将这些更改写回磁盘，才能将缓冲区重用于其他页），并使它们可用于用户进程。 |
该指标的值 最好为 0。 |
个数 /秒 |
|
Cache Manager(高速缓存管理器)(Plan Cache) |
|||
|
高速缓存命中率(Cache Hit Ratio%） |
指高速缓存命中次数和查找次数的比率。在SQL Server中，Cache包括Log Cache，Buffer Cache以及Procedure Cache，该指标是指所有Cache的命中率，是一个总体的比率。 |
该指标的值越高越好。如果该指标的值持续低于80%，就需要增加更多的内存。 |
|
|
SQL Server中闩（Latches） |
|||
|
平均闩等待 时间(毫秒) (Average Latch Wait Time(ms)) |
指一个SQL Server线程必须等待一个闩的平均时间。 |
如果该指标的值很高，则系统可能正经历严重的资源竞争问题。 |
毫秒 |
|
闩等待/秒 (Latch Waits/sec) |
指在一个闩上每秒的平均等待数量。 |
如果该指标的值很高，则系统可能正经历严重的资源竞争问题。 |
个数/秒 |
|
General Statistics |
|||
|
user connections |
指系统中活动的SQL连接数。该计数器的信息可以用于确定系统得最大并发用户数 |
个数 |
|
|
Locks |
|||
|
lock requests/sec |
指每秒请求的锁个数。 |
通过优化查询来减少读取次数，可以减少该计数器的值。 |
个数/秒 |
|
lock timeouts/sec |
指每秒由于等待对锁的授权的锁请求数， |
理想情况下，该计数器的值为0 |
|
|
lock waits/sec |
指每秒无法立刻得到授权而超时的锁请求数， |
理想情况下，该计数器的值应该尽可能为0 |
|
|
Average Wait Time |
线程等待某种类型的锁的平均等待时间 |
通过优化查询来减少读取次数，可以减少该计数器的值。 |
毫秒 |
|
number of deadlocks/sec |
指每秒导致死锁的锁请求数。死锁对于应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器必须为0 |
锁加在SQL Server资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。应尽可能少使用锁以提高事务的并发性，从而改善性能。 |
个数/秒 |
|
Memory manager |
|||
|
memory grants pending |
指每秒等待工作空间内存授权的进程数。该计数器应该尽可能接近0，否则预示可能存在着内存瓶颈 |
||
|
Lock blocks |
服务器上锁定块的数量，锁是在页、行或者表这样的资源上。 |
不希望看到一个增长的值。 |
|
|
Total server memory |
sql server服务器当前正在使用的动态内存总量. |
||
|
SQL statistics |
|||
|
batch requests/sec |
指每秒向服务器提交批的请求次数。 |
该计数器被用来确定系统的负载大小 |
|
|
SQL compilations/sec |
指每秒编译数。 |
理想状态下该计数器的值应该低，如果batch requests/sec计数器的值非常接近该计数器，那么可能存在大量的特殊SQL调用 |
|
|
re- compilations/sec |
指每秒的重新编译数。 |
该计数器的值越低越好。存储过程在理想情况下应该只编译一次，然后被他们的执行计划重复利用。如果该计数器的值较高，或许需要换个方式编写存储过程，从而减少重编译的次数 |
|
最后，附上本文的相关资源：