每次去IT社区，都在吐槽：说技术人员是多么的苦逼；每次和一些搞技术的朋友聚会，聊的也是大家的生活是多么的苦逼；每次上网看微博，也是充斥着“技术人员苦逼论”…
今天谈到这个话题，固然会有很多的不同的意见和想法，我这里这是就从我看到的一些现象和自己的一些思考说说技术人员到底为什么“苦逼”。
为什么苦逼？
原因一大堆，对于外部的因数，我们很难控制，例如中国的IT国情和对技术人员的观念。但是，在商业中有这样一句话可以借鉴一下：经济再萧条，也有人在赚钱；形式再好，也有很多人在亏本，很多的公司在倒闭。
很多的时候，我们倒苦水，但是心里要知道：是大的环境让我们苦逼，还是我们本身就得苦逼，换句话说，苦逼是我们自己应得的。这话很多人不爱听，但是很多时候确是事实。
这半年多以来，去了不少大大小小的公司，为他们的项目进行救火，解决他们现有的性能等问题。很多的项目在做的时候，很少考虑什么性能，安全等因素，都是上面的人在不断的催，下面的人在火急火燎的加班加点赶进度—今天完成了什么功能点，明天要完成什么功能点。于是很多的技术人员顾不上什么，一心思的把功能堆了起来。苦逼的第一个原因出来了。
终于，项目搞定了，上线跑了没有多久，问题就出来了：项目功能是齐全，但是就是无法使用，有的功能慢的像拖牛。于是，有人建议开始买好的设备，加大带宽，以为钱砸下去了，情况会好点。但是好景不长，甚至事与愿违。于是一堆人就开始焦虑，束手无策，技术人员又开始加班加点的解决明明知道自己无法解决的问题，于是苦逼的第二个原因出来了。
在无法搞定的情况下，技术人员开始郁闷了，接着疯狂的上网开始收集可能的偏方，然后一股脑的用在项目中，求神拜佛的希望偏方有效果，运气好，暂时搞定了，那就皆大欢喜，搞不定，把之前的步骤再次重复一次吧。基本可以用下面的一个幽默来总结这个过程:
从接触到的一些技术朋友来看，有些朋友的技术能力不错，有的却让我想抽自己，没有听错，是抽我自己。抽我自己为什么要给他们讲这么多的东西，而这些东西他们又不懂，然后又非得把懂这些知识的铺垫知识给他们讲。例如，项目出现了内存泄露的问题，公司的技术人员问题我这么回事，于是我告诉他们是VAS的碎片，他们又问我们为什么VAS碎片了，于是我们给他们讲述，但是他们听不懂，于是让我们给他们讲解一些铺垫知识：Window内存机制，.NET内存机制等。本来以为大家都是同行，交流交流，没想到，使得我们自己陷入了苦逼：
同时也深深的感受的一点：很多的技术朋友在走出了校门或者培训学校之后，技术能力就没有在进步了，一是处于打混的阶段，有的运气好，很多年之后，混到了不错的职位，但是很多的人却混的非常不幸，于是他们就成为“技术人员苦逼论“的忠实粉丝。其中有一点就是很多的朋友不喜欢自学，总是希望有人手把手的教。我们遇到的一个最搞人的情况就是，我们已经把功能全部调完了，代码完全实现了，服务器也是全部配置好了，就差调试了，很多的人依然不动。
也使得我想起另外一个情况：每次有很多的朋友都说要学习技术内幕，要学深一点，喊着叫着要看深一点的文章，但是写出来之后，没有几个人真正的看完，前几篇简单的介绍看的人很多，稍微深一点，就没有人看了。也有很多的朋友想到处找大牛拜师，都希望沾点牛气，成为牛中的一员。但是技术，能力，这个东西终究靠自己。用心与不用心，差别就是天壤之别。
我常常说这样的话：社会不是初中，高中，没有人会像老师那样手把手的教你，盯着你，一切靠自己。没有谁就非得要叫你，没有人欠你的，如果自己都不上进，想做阿斗，诸葛亮来了也没用办法。物竞天择，适者生存！
我非常敬佩那些出身不好但是一直坚持奋斗的人，也非常敬仰那么环境舒适还依然努力的人。你遇到过很多聪明人，你的大学同学，你的同事，你的朋友，有几个比你傻？很多年以后，你会看到成功的并不是最聪明的人。因为决定成功的更多是非智力因素：明确的目标，积极的心态，努力和坚持，承受挫折和压力的能力，成熟的接人待物等等。有一种人注定没戏：不努力和怨天尤人。
看到这里，技术人员为什么苦逼，可能各人心中有了答案。有机会，我们再谈。
此主题介绍了可以用来监视下列硬件组件的计数器，并包括了每个组件的建议值和其他调整策略。
监视内存（上）
监视处理器容量 （上）
监视多处理器系统（上）
监视网络容量和带宽 （下）
监视和优化硬盘（下）
文章列表
监视和调整硬件性能（上）
监视和调整硬件性能（下）
推荐阅读：技术人员，为什么会苦逼
监视内存
解决内存不足的问题之后，IIS 上将获得最大的性能改善。在作出任何有关更改硬件配置的决定之前，应首选排除内存问题。应首先监视内存以验证服务器是否有足够的内存，然后再继续处理服务器环境其他部分的问题。内存不足引起的问题常常会表现为系统的其他部分的问题。对于电子商务站点、具有许多内容的站点，以及流量非常大的站点，内存更大一点特别有益。
可以使用系统监视器判断服务器上的当前内存量是否满足需要。系统监视器以图形方式显示计数器读数随时间的变化。
监视下面的计数器来判断是否存在与内存有关的性能瓶颈：
| 计数器 | 监视 |
|---|---|
| Memory\Available Bytes | 试图保留至少 10％ 的可用内存以供高峰时间使用。 |
| Memory\Page Faults/sec
Memory\Pages Input/sec Memory\Page Reads/sec Memory\Transition Faults/sec |
如果进程请求内存中的某个页面而系统无法在请求的位置找到它，就会产生页错误。如果该页在内存中的其他地方，那么该错误叫做软页错误（由 Transition Faults/sec 度量）。如果该页必须从磁盘中检索，那么该错误就叫作硬页错误。大多数处理器可以处理大量的软错误而不会造成任何后果。然而，硬错误会造成严重的延迟。
Page Faults/sec 是处理器处理硬页错误和软页错误的总体速率。Pages Input/sec 是为解决硬页错误而从磁盘读取的页的总数。Page Reads/sec 是为解决硬页错误而读取磁盘的次数。Pages Input/sec 将大于等于 Page Reads/sec，并可以使您很好地了解硬页错误率。如果这些数字较低，则服务器响应请求的速度可能很快。如果它们较高，可能是因为您为缓存分配的内存太多，而没有为系统的其他操作保留足够的内存。可能需要提高服务器的 RAM 量，虽然减少缓存大小也是一个有效办法。 |
| Memory\Cache Bytes | 显示文件系统的大小。默认情况下，缓存被设置为最多可以使用 50％ 的可用物理内存。由于 IIS 会自动在内存不足的情况下减少缓存，因此要确保监视此计数器的趋势。 |
| WWW service cache\File Cache Flushes
WWW service cache\File Cache Hits WWW service cache\File Cache % |
这些计数器描述了用户模式文件缓存。文件缓存基本上是一个文件名或者文件内容缓存。如果用户请求一个文件，IIS 就会搜索文件缓存，如果它位于缓存中，就返回该文件。如果 IIS 在缓存中找不到该文件，它将从硬盘中读取并返回该文件，从而导致硬页错误。
File Cache Flushes 表示了 IIS 从万维网发布服务 （WWW 服务)缓存中清除条目的次数。如果文件已经更改或者如果在 30 秒内没有访问文件，将清除条目。如果该计数器值较高，IIS 就用没有被访问的文件填充缓存，随后再将这些文件清空。 File Cache Hits 是 IIS 在缓存中找到文件的次数。
File Cache % 是缓存命中率。这是 IIS 在缓存中找到请求的文件的次数百分比。如果缓存命中率较低（例如，70％），您可能需要考虑围绕能轻易在文件缓存中找到的少量的“热门”信息重新设计站点，从而改善性能。 |
| Process\Page File Bytes
Process\Page File Bytes Peak Paging File\% Usage Paging File\% Usage Peak |
这些计数器反映了在使用中的页面文件实例的数量。页面文件越大，系统提交给它的内存越多。Windows Server 2003 家族成员在系统驱动器上创建页面文件。可以在每个逻辑磁盘上创建页面文件，并可更改现有文件的大小。事实上，通过跨多个单独的物理驱动器对页面文件进行条带化，可以改善页面文件的性能（即，它所使用的驱动器不包含站点的内容或日志文件）。记住，系统驱动器上的页面文件至少应是物理内存大小的两倍，这样，系统便可以在系统意外地锁定或关闭的情况下将 RAM 中的全部内容写入磁盘。 |
| Memory\Pool Paged Bytes
Memory\Pool Non-paged Bytes Process\Virtual Bytes (W3wp.exe) Process\Virtual Bytes (Inetinfo.exe) Process\Working Set (W3wp.exe) Process\Working Set (Inetinfo.exe) |
Pool Paged Bytes 和 Pool Non-paged Bytes监视服务器上的所有进程的池空间。
Virtual Bytes 计数器既可以通过 Inetinfo.exe 进程，也可以通过在服务器上实例化的 W3wp.exe 进程（来监视 IIS 直接保留的虚拟地址空间的量。 Working Set 计数器计量每个进程使用的内存页面的数量。一定要监视服务器上的 W3wp.exe 的所有实例的计数器；否则，您就不能获得 IIS 使用的虚拟内存的准确读数。系统的内存池保留了应用程序和操作系统创建和使用的对象。内存池的内容只有在特权模式下才可以访问。即，只有操作系统的内核才能直接使用内存池；而用户进程不能直接使用。在运行 IIS 6.0 的服务器上，为连接提供服务的线程与该服务使用的其他对象（如文件句柄和套接字）一起存储在非页面缓冲池中。 |
除了添加更多的 RAM 外，还可以使用下面的过程来提高内存性能。
- 改善数据组织。
- 使用磁盘镜像或带区。
- 用托管代码（ASP.NET）或 Internet 服务器 API (ISAPI) 应用程序替换通用网关接口 (CGI) 应用程序。
- 增大页面文件。
- 消除不必要的功能。
- 改变文件系统缓存与 IIS 工作集之间的平衡。
监视处理器容量
由于用户要求网站有快速的响应时间以及这些站点能提供不断增加的动态生成的内容量，快速和有效的处理器使用应放在首位。当一个或多个进程消耗了大多数处理器时间时，就会发生瓶颈。这会迫使已准备执行的线程在队列中等待处理器时间。添加其他硬件，无论是内存、硬盘还是网络连接，以试图克服处理器瓶颈并非有效办法，并可能会引发更大的问题。
监视下列计数器以判断是否存在与处理器容量相关的性能瓶颈：
| 计数器 | 监视 |
|---|---|
| System\Processor Queue Length | 显示队列中等待执行的并由系统上的所有处理器共享的线程的数量。如果此计数器有两个或两个以上的持续不变的线程，则说明服务器出现瓶颈。 |
| Processor\%Processor Time | 处理器瓶颈的特征在于这样的情况，其中，% Processor Time 数字较高，而网络适配卡和磁盘 I/O 低于容量值。在多处理器计算机上，请检查 % Processor Time 计数器，以查找处理器和处理时间之间的任何不平衡现象。 |
| Thread (svchost/host number)\Context Switches/sec
System\Context Switches/sec |
如果您决定增加任何线程池的大小，则应监视此计数器。提高线程的数量可能会将上下文开关的数量提高到某一点，造成性能降低而不是提高。如果每秒钟上下文开关达到一万或更多，则说明该计数器的值较大。如果看到该数字有这么大，则请考虑降低线程池的大小。可能很难平衡线程与由连接和请求计量的总体性能。每次调整线程时，都应进行总体性能监视，以了解性能是提高还是降低了。
要判断是否应调整线程计数，应将线程数量和进程中的每个线程的处理器时间与总处理器时间进行比较。如果线程持续处于忙状态，但没有完全使用处理器时间，则可以通过产生更多的线程来改善性能。然而，如果所有线程都忙，并且处理器接近于它们的最大容量，最好在多台服务器之间分布负载而不是提高线程的数量。 |
| Processor\Interrupts/sec
Processor\% DPC Time |
可以使用这些计数器判断处理器花费在中断和延迟的过程调用上的时间长短。这两个因素可能是造成处理器上负载的另一个原因。客户端请求可能是中断和延迟的过程调用的主要原因。一些新的网络适配卡包括中断调解，它会在中断的级别太高时将中断堆积在缓冲区中。 |
监视多处理器系统
IIS 可以在多处理器计算机上缩放，但可伸缩性可能会由于网站和 Web 应用程序的拙劣设计而削弱。Web 园和进程回收可以帮助最大限度地减少与不完善的应用程序相关的性能问题。然而，一定要监视和测试多处理器计算机上的网站和 Web 应用程序的可伸缩性。在更改多处理器计算机的设置之前，应排除系统的所有其他方面的瓶颈。
还应考虑向特定的处理器指派进程（叫做处理器关系），以更好地管理服务器处理请求和应用程序处理的方式。此外，在更改多处理器计算机的设置之前，应在 IIS 中启用服务质量功能。服务质量功能用于限制特定网站或 Web 应用程序使用的资源，以确保系统的其他部分有足够的资源使用。
监视下列计数器以判断是否存在与多处理器计算机相关的性能瓶颈：
| 计数器 | 监视 |
|---|---|
| Processor\% Processor Time (_Total) | 通过将采样间隔内所有处理器的平均非空闲时间相加并将总和除以处理器的数量，即可衡量计算机中所有处理器的处理器活动。例如，如果平均起来，所有处理器在半个采样间隔内处于忙状态，则显示 50%。如果半数处理器在整个间隔内处于忙状态，而其他的处理器处于空闲状态，也显示 50%。 |
| Thread\% Processor Time (_Total/_Total) | 衡量线程的处理器时间量。 |
管理多处理器系统中的处理器关系
设置处理器关系意味着向特定的处理器指派特定的进程或应用程序。控制处理器关系可以通过减少线程从一个处理器移动到另一个处理器时处理器缓存刷新的次数来提高性能。对于专用的文件服务器，这可能是一种好的选择。然而，请注意，为程序分配特定的处理器可能会不允许其他程序线程迁移到最不繁忙的处理器。
如果要为一个处理器指派特定的进程或程序，以牺牲其他进程为代价提高其性能，则请在 IIS 配置数据库中更改 SMPProcessorAffinityMask 属性
我们通过减少查询中的不必要的读取操作从而使得查询的性能得到提升。一个查询在数据库中执行的读操作越多，那么就对磁盘，CPU，内存的压力越大。除非整个数据库的数据全在在内存中，否则每次的读操作都会把数据从磁盘读入到内存中，然后返回。
一个查询在读取一个资源的时候，通过加锁会阻止其他的查询对这个资源进行修改，此时其他要操作这个资源的查询就需要等待，从而导致了延时。
诚然，有些等待是必须的，读取操作也是必须的，但是一些因为我们代码或者设计导致的过度的读取操作和等待，那就会严重影响性能，尤其是当数据库的访问量开始变大的时候。
可以说在SQL Server中，最高效的读取数据方式就是通过索引去获取数据。如果在数据表中存在缺失索引的问题，结果可想而知。
在本篇中，我们将会讨论下面几个议题：
- 如何识别缺失索引性能问题
- 识别没有用的索引
- 如何解决上面的问题
确实本篇讲述的内容涉及到了一些与数据库性能调优的话题，对于调优而言，难点很多时候在于如何正确的找出性能问题。
下面，我们首先来看看缺失索引。
缺失索引
SQL Server可以在表字段上面建立索引，从而使得Where和Join这样的语句执行的更快。当查询优化器在优化一个查询的时候，它会保存一些来暗示哪些列上可能建立索引之后可能性能会更快的信息。我们可以通过动态管理视图sys.dm_db_missing_index_details来查看,运行如下查询
查询的结果如下：
下面，我们就来稍微的解释一下结果中主要字段的含义：
|
字段名字 |
说明 |
|
DatabaseName |
告诉我们是哪一个数据库上面存在缺失索引的问题 |
|
equality_columns |
如果在某个字段上面进行了相等的操作，例如Name=’Agilesharp’，在Name字段上面进行了判等的操作，如果查询优化器认为这个Name上面缺失索引，那么这个Name就会出现在上述查询的结果中。 多个字段，用逗号分割 |
|
inquality_columns |
在某个字段上进行了不等的操作，例如ID>1等，如果ID上面存在缺失索引，那么ID就会出现在这里 |
|
Included_columns |
告诉我们那些数据列可以作为索引包含列放在索引中，从而减少书签查找的开销 |
|
Statement |
告诉哪一个表上面存在缺失索引的问题 |
当然，上面的DMV查询所得到的结果只是推荐结果，至于是否要去在相应的列上面建立索引，还需要进行综合的分析，不能单靠一方面来判断，例如，我们可以在去制定一些计划去运行SQL Profiler去跟踪数据库，然后分析跟踪的数据，并且分析这个列的数据的分布情况，分析数据的密度和差异性，而且还可以进一步的分析列的统计信息，然后决定是否要加索引。
注：我也正在写SQL Server Profiler的文章，还没有发布，请大家耐心等待。另外SQL Server的调优是个非常深的话题，大家可以通过我这里的一些问题在掌握一些所谓的小技巧，起到一个抛砖引玉的作用！
说了这么多，可能大家感觉像是没有说，感觉有点虚。确实，我也感觉这样，因为就这分析缺失索引的问题要考虑的问题就N多。agilesharp的其他系列文章也在讨论SQL Server的性能问题，这里，我们就不多说，也不把问题搞复杂了。我再送朋友一段分析的代码，可以更好的帮助我们找到缺失索引的问题:
上面的查询比较不错，按照成本进行了分析，成本越大，就说明加了索引之后，收益就越大，可以看到如下的结果：
然后大家加了索引之后，可以多多的测试，可以查看执行计划，也可以查看查询的数据页的读取情况，I/O的情况：
没有用的索引
正如在上一小节所的讲的，创建一个索引是一个非常需要重视的问题，需要考虑很多的方面，因为，如果我们建立的索引没有发挥作用，甚至说，查询优化器不采用我们的索引，那么就会带来适得其反的效果。
索引的维护是需要成本，甚至使得数据库的性能变得很低，特别实在数据更新的时候。当在数据表上面进行数据的更新，删除，和插入的时候，都会导致索引页发生重新的调整，导致索引页中的数据重新的排序，从而导致数据表被锁定。
所以，我们很有必要找出没有发挥作用的索引，我们还是可以采用DMV来快速的查看：
这里不否认，要完全明白上面的查询的意思却不是一件容易的事情，大家可以暂时不用懂，可以把这些脚本保存起来，作为一个小的工具使用。
查询结果如下：
因为我这里采用的是一个示例数据库，所以看到的结果不是很多，但是可以发现：这些索引一些在被不断的更新（user_updates），但是没有被用过（system usage）。
对无用索引的解决很简单：删除索引就OK了。
关于脚本，请大家在附件中下载，可以保留起来，并且大家还可以修改，查询指定的数据库的情况。
随着自己不断的在技术这条路上走着，感悟和体会也是越来越多！和大家分享上几点。
1. 懂得越多，发现自己懂得越少
现在回想以前，发现以前的自己确实有点“轻狂”，在简历上面写上自己对某些方面很是“精通“，对”XXX内核“颇有研究… 现在回想起来，真是为当初的自己捏了把汗：真是初生牛犊不怕虎，幸好没有遇上”屠牛人“。
现在发现，当初的自己对技术的掌握是很肤浅的，以为懂得了一点点所谓的底层机制，就以高手自居；以为懂得了一点点的性能优化的偏方，以为就是天下无敌；以为自己懂得了一些设计的方面和模式，就可以笑傲江湖。虽然那时候也是相信“天外有天，人外有人“，但是一直以为自己没有遇到这样的”人外人“。
在技术的学习和职业的发展过程中慢慢的发现：对很多的东西的掌握，不是那么容易，也不可能一蹴而就的。
就拿性能调优而言，记得当初偶然去了一个公司，那个公司对性能有一些要求，在面试的时候，问了一些与性能相关的问题，也问了我会不会使用SQL Profiler。那时候的自己，可以说对性能优化懂得也不是不多，只是可以从网络上找到一些最最基本的方法，例如不用in，而是用exists等等。经过这次的面试自己感觉自己存在很多的不足，于是开始不断的到处寻找资料学习，也阅读了不少的东西，也做了很多的一些测试性的实践，于是以为就已经懂得了调优。
后来才发现：原来技术这趟水很深很深：通过使用SQL Profiler，确实可以看出一些端倪，发现一些可能的问题，但是，这些问题到底是不是问题，那么就需要分析，在分析的过程中，就需要更多的知识来判断，例如要学会读懂执行计划，要懂得统计数据。
后来进一步发现，要懂得关系引擎内部是如何运作的，也发现调优不是一个表面的功夫，不是随便改改join的顺序就可以的，需要深入的理解每一个步骤，确保每一点都是尽可能的最优的。后来发现需要懂得和实实在在的掌握优化器内部的工作原理。终于花了很长的时间和功夫学会了这些方面的东西，以为这就是全部，可是发现自己还是有点“不给力“，就拿内存问题而已，以为看看一些计数器和动态管理视图就可以分析了的，后来发现，还需要理解Windows的底层机制，需要懂的内存的分配与管理，而这些，以前都是没有接触到的，以为SQLOS的内存分配方式与Windows的毕竟是不同的，有着自己的特点….
于是这样一步步的刨根究底，越来越感觉以前自己懂的太少。少了一些轻浮，慢慢的开始内敛。
有时候回头想想，也许有人认为你是SB:有必要搞的这么深吗。诚然，国内的技术氛围，有些浮躁。但是把东西掌握的实实在在，深入，是很有必要的。
说到这里，我想起我前几天看的一个电影，名字好像是“拯救地球“，说的就是地心出了问题，造成地球的磁场有问题，会导致人类灭亡。不同的人看电视有不同的观点和想法，从这些影片中，我在看的时候，很是担心里面的科学家是理论派：讲起知识，那是天下无敌；做起事来，一无是处。
因为现在是把人送到地心，任何一点点的失误，就是死亡，并且死的很惨，想想一下：人在几千里的地下被埋，被压死，被岩浆烧死，窒息而死…
如果这些科学家对地球的研究不深入，不确确实实的直到地球内部的情况，结果可想而知…
技术也是一样的！
2．不要迷恋传说与神话，自己才是自己的救星。
以前的自己，也是崇拜很多的大牛，一切向大牛看起，甚至是对他们痴迷，更加希望自己大牛们看的书，需要搞完他们的看书的清单，更加的奢望他们对自己指点一二，打通任督二脉。
后来开始发现：一切靠自己。
这句话，谁都懂，但是不是每个人都做得到的，包括我自己。
不否认，有时候，别人在必要的时候，给你一些提示，确实可以对自己的发展，甚至人生有很大的作用，但是一切的成功和收获，还是靠内因。
记得以前在讲课，写文章的时候，很多人都希望一下子通过你讲述的内容成为高手，也很多人喜欢花几天的培训，一下次“悟道升仙“。如果他们所花的时间或者金钱没有达到他们想要的结果时候，会骂你，这个时候，要理解他们。其实回头想想：如果真的这么容易，那么高手也就不值钱了，以为随随便便搞个培训，读点文字就搞定了，正是因为难，才会把人不断的淘汰，才会有最后的充满泪水的微笑。
3. 你如何对人，人如何对你，你如何对事，事如何对你，常常审视自己
在生活中，难免会存在一些人与自己相对，也不可能你被所有的人接受。有人天生就是看不惯你，有人就是对你“羡慕嫉妒恨“。以前，这些情况发生在自己身上的时候，总是要生点闷气，心里不爽，后来看淡了：人生没有几个十年，把时间花早生气上面，不如花在更加有意义的事情上面。
说的很容易，其实做起来蛮难的。其实有时候，可以反过来想想：与其花时间去与那些人争吵，打口水战，不如想想为什么他们针对你，或者说，你的哪一点是被他们看不爽的，如果他们是嫉妒你的能力和成就，那么你就“化愤怒为力量“，让你的成就更大一点，气死他们，呵呵呵，让他们永远不能超过你，让他们永远或者嫉妒悲愤中。
其实对一个人的打击和创伤，不是把人搞死搞残，而是说把人的心搞死，一个人心死了，什么都没有了，一个人，只要心不死，一切都有可能。
人，最不能忘记的，是在你困难之时拉你一把的人；最不能结交的，是在你失败时藐视你的人；最不能相信的，是在你成功时吹捧你的人；最不能抛弃的，是和你同创业共患难的人；最不能爱的，是不看重你人格的人。
送上一句话：一个人的度量有多大，成就就有大多。
系列文章：
负载均衡原理与实践详解 第三篇 服务器负载均衡的基本概念-网络基础
负载均衡原理与实践详解 第九篇 服务器负载均衡技术进阶-会话保持（上）
负载均衡原理与实践详解 第十篇 服务器负载均衡技术进阶-会话保持（中）
到目前为止，我们已经详细讨论了使用负载均衡器来提高服务器群可扩展性、可用性、可管理性的几种功能和特性。本章我们主要讨论负载均衡器部署的问题，讨论在现有的网络中部署负载均衡器的几种方案。我们还将讨论如何设计高可用的方案，以实现整个网络中不同网络组件的容错处理，包括负载均衡器在内。
在讨论网络结构之前，我们需要了解一些基本概念。首先讨论是否把负载均衡器当作二层交换机或三层路由器来使用，这在网络设计中是非常关键的。然后从不涉及到高可用性的简单的网络结构入手，延伸到负载均衡器如何实现双机的高可用性，并将讨论不同的高可用性设计和必需的条件。本章将详细描述网络结构由简单到复杂的变化过程，而不只是提供一个特定的网络设计方案。
1把负载均衡当作二层交换机还是三层路由器
交换机的基本功能就是在接收端口接收数据包，选择输出端口并将数据包发送出去。如何选择输出端口取决于交换机的具体类型。
二层交换机利用数据链路层的MAC地址来决定数据包的输出端口。三层交换机，也就是路由器，利用网络层的信息来决定数据包的输出端口。当采用IP协议时，三层交换机利用数据包中的IP地址来决定数据包的输出端口。
客户端和服务器，通常被称为主机，会把管理员提供的路由器的IP地址设置为缺省网关。当给不同网段的IP地址发送数据包时，主机会把数据包发送给缺省网关。路有器作为缺省网关会利用路由协议根据数据包的IP地址来决定如何转发数据包。
负载均衡器一般在四层或者四层以上工作，这取决于我们使用的功能特性。当接收到目地址是VIP并以负载均衡器的MAC地址为其目的MAC地址的数据包后，负载均衡器根据数据包中四层以上的信息实现负载均衡功能。
通过利用数据包中的信息和服务器健康检查的结果以及服务器负载的状态，负载均衡器选择一台真实的服务器来提供服务，并将请求转发到这台服务器。同时负载均衡器会修改数据包中的相关信息，例如目的IP地址、TCP或者UDP端口号码。修改数据包之后，负载均衡器需要确定输出端口并发送这个数据包，负载均衡器可以象二层交换机或路由器那样转发数据包。
负载均衡器只对特定的数据包提供四层以上的交换，那就是以VIP为目的地址并有相应服务器回应的数据包。所有其他的数据包均在二层或三层交换，这取决于负载均衡器的配置。
图1是负载均衡器在二层工作模式下数据包转发和IP寻址的过程。
服务器和负载均衡器的缺省网关都指向路由器。所有的服务器都在同一个网段内，这样，服务器之间可以通过负载均衡器直接通讯，而不需要经过路由器。需要注意的一点是，从服务器端返回的数据包的目的MAC地址是M1，即路由器的MAC地址。但是由于服务器采用公网IP地址，无法节省IP地址资源，所以这种方案没有吸引力。
这样也无法防止用户直接访问服务器，除非在路由器或负载均衡器上设置访问控制列表。可以让服务器使用私网IP地址，但是这样就有需要在路由器同一个接口上面配置两个网段。
负载均衡器使用公网IP地址在一个网段，服务器使用私网IP地址在另外一个网段。我们需要在路由器跟负载均衡器相连的接口上定义两个IP地址：一个IP地址在VIP的网段，而另外一个IP地址在服务器的网段。有些负载均衡产品提供一些特殊的功能，可以避免在路由器接口上设置多个IP地址。
服务器的缺省网关指向负载均衡器时，数据包的流程和IP寻址过程如图2所示，负载均衡器象路由器一样转发数据包。缺省网关的地址为：10.10.10.1，定义在负载均衡器连接服务器的接口上。本文中使用网关IP来表示服务器缺省网关的IP地址。
因为缺省网关指向负载均衡器，服务器回应的数据包的目的MAC地址是M2，也就是负载均衡器的MAC地址，如图2所示。
有人会问，为什么不用VIP来做服务器的缺省网关？当然可以，但是可能会有多个VIP，每个VIP为不同的客户和应用提供服务，而服务器的缺省网关只能有一个。所以，采用单独的IP地址作为缺省网关，跟VIP地址分开是比较合理的。另外，网关IP地址必须与服务器在同一网段。如果服务器分布在不同的网段，每个网段都需要定义一个缺省网关。所以，把VIP和缺省网关分开会比较方便。
路由和交换功能跟整个负载均衡功能是分开的，路由和交换功能就是根据IP地址或者MAC地址来决定下一跳和输出端口，而负载均衡功能在OSI模型中的更高层工作。如果真实服务器和负载均衡器在同一个网段或者广播域，负载均衡器可以通过第二层交换把数据包发送到真实服务器上。如果服务器和负载均衡器不在同一个广播域，如何转发数据包就取决于负载均衡器是在二层工作还是在三层工作。如果负载均衡器是一个三层交换机，它会根据路由表来决定下一跳的地址。如果负载均衡器是一个第二层交换机，负载均衡器会把数据包发送到缺省网关，由缺省网关把数据包路由到真实的服务器。
如果负载均衡器是以三层路由器的方式进行工作，还有一个好处，服务器可以把缺省网关指向负载均衡器。这样就保证了在特定的网络环境中服务器回应的数据经过负载均衡器，例如单臂网络环境中。
我们接下来要讨论的一些网络设计中会用到这种功能。另外，负载均衡器能够对外部交换机和路由器隐藏服务器的私有IP地址。如果服务器在不同的网段，它们可以通过负载均衡器互相通信。不过，负载均衡器以三层路由的方式进行工作时，在配置和管理上要比二层工作方式稍微复杂一点。通常，只要求负载均衡器进行简单的路由，不会运行BGP之类复杂的路由协议。
在后续部分，假定负载均衡器以三层路由的方式进行工作，所以服务器的缺省网关都指向负载均衡器。
解析索引中数据列顺序的选择问题
在多个列上面建立索引的时候，我们常常会遇到这样的一个问题“需要把哪个列放在前面”，因为索引中列顺序的不同，会对索引的使用，以至性能产生很大的影响。我们本篇就来分析这个问题。
对于上面的问题，一个常见的回答就是“把选择性最大列放在前面”，这里为了使得后面的讲述顺序进行，我们先来解释一下选择性的含义。选择性是用来描述数据的差异情况的，例如，如果一个表中有1000条数据，其中的某个字段，如ID，如果每一条数据的ID值都不一样，那么ID的选择性就是1；如果其中有300百个ID是一样的，那么就是说，有700个ID不同，那么选择性就是70%。很显然，数据的选择性越高，那么在上面建立索引效果就越好。
下面，我们就来解释一下为什么在多个列上面建立索引的时候需要把选择性高的列放在最前面。
也许有朋友听到上面的建议之后，在建立任何基于多个列的索引的时候，都会把表的聚集索引所在的列作为这个多列索引的第一个字段。例如，假设现在表中有4个字段，ID,Name,Age，BirthDate，其中ID是主键，也是聚集索引，现在我们需要在Name,BirthDate上面建立索引，这个时候，有朋友发现：ID的选择性最高，那么把ID放在新的索引中，势必会更好，于是一个名字为IX_Index的索引就包含了三个列：ID,Name，BirthDate。到后来，可能就发现，如果冒冒然的这样做，使得这个新建的索引没有发挥作用，反而导致性能问题。
对于数据库中的每一个索引，都会有相应的统计数据信息，这个统计数据显示了数据的分布情况，统计信息以一个类似柱形的形式表现了数据的分布。数据库只把索引中的第一个列的数据分布情况放在柱形图中，换句话说，这个统计信息显示的就是索引中的第一个数据列的数据分布情况（这里面涉及到的内容有点深，大家可以关注本站点的“查询优化器内核系列”，里面会讲述到）。
我给大家看个例子吧，假设在SalesOrderDetail表上面有一个索引：X_SalesOrderDetail_ProductID，运行下面的语句：
这个索引包含的列有：ProductID，SalesOrderID和SalesOrderDetailID。我们查看它的数据的柱形分布图，如下：
我们发现，其中的RANGE_HI_KEY列出的就是ProductID的值，通过图中，我们可以知道：ProductID值为826的数据有305条，值为831的数据有198条。ProductID的值在826到831之间的数据有110条。查询优化器就是根据这个来估算数据的条数的。
通过上面可以知道：把索引中的哪个列放在前面至关重要，如果把一个选择性很低的列放在前面，那么就导致索引的统计数据显示的数据分布完全改变，可能导致查询优化器选择比较低效的执行计划。
下面，我们就通过一个例子来进一步的看看这个问题。
首先，建立一个测试的表，如下：
这个表中有10000条数据，并且这个表是一个堆表，即没有聚集索引的表。并且在这个表中有100个不同的SomeString值，有5000个不同的SomeDate值，而ID是唯一的，全部都不同。
那么，上面的值的选择性如下：
|
字段名 |
选择性 |
|
ID |
100% |
|
SomeString |
100/10000*100%=1% |
|
SomeDate |
5000/10000*100%=50% |
在表中，有一个非聚集索引，假设名字为Idx_test，包含了表中的三个值，三个列在索引中的顺序为：ID,SomeDate，SomeString，按照选择性排序，确实不错！
对于上面的索引，只有在类似下面的查询结构中发挥作用，如下：
… WHERE ID = @ID AND SomeDate = @dt AND SomeString = @str
… WHERE ID = @ID AND SomeDate = @dt
… WHERE ID = @ID
换句话说，就是这个索引只在查询中的Where/Join的列按照索引中的列的顺序使用的时候才有效。如果查询是这样的，如下：
… WHERE SomeDate = @dt或者… SomeDate = @dt AND SomeString = @str
那么，这个索引就不会上面的查询中使用了，那么查询在执行的时候就会扫描整表了。
我们通过执行计划来看看是不是这样的。
对于，WHERE ID = @ID的查询，执行计划如下：
很显然，执行了Seek操作，是很快的。
对于WHERE ID = @ID AND SomeDate = @dt的查询，执行计划如下：
还是进行了Seek操作。
那么对于… SomeDate = @dt AND SomeString = @str的查询，如下：
大家可以看到，这个时候已经开始进行全表扫描了。
我们本篇讲述了在索引的进行列的相等操作时候，列的顺序问题，我们下一篇就讲述如果是在列上进行不等操作，例如ID>1，那么索引中的列的顺序还是这样进行吗？
系列文章链接：
IIS负载均衡-Application Request Route详解第一篇： ARR介绍
IIS负载均衡-Application Request Route详解第二篇：创建与配置Server Farm
IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡（上）
IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡（下）
IIS负载均衡-Application Request Route详解第四篇：使用ARR实现三层部署架构
负载均衡原理与实践详解 第三篇 服务器负载均衡的基本概念-网络基础
负载均衡原理与实践详解 第九篇 服务器负载均衡技术进阶-会话保持（上）
负载均衡原理与实践详解 第十篇 服务器负载均衡技术进阶-会话保持（中）
负载均衡原理与实践详解 第十一篇 服务器负载均衡技术进阶-会话保持（下） 之：延迟绑定
我们在本篇中接着讲述“工作进程回收机制”。
本篇文章的议题如下：
工作进程回收机制讲解
基于时间的回收机制
基于请求数的回收机制
基于内存使用的回收机制
基于活动状态的回收机制
系列文章：
构建高性能.NET应用之配置高可用IIS服务器-第一篇：IIS必须掌握的知识
构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型
构建高性能.NET应用之配置高可用IIS服务器-第三篇 IIS中三个核心组件的讲解（上）
构建高性能.NET应用之配置高可用IIS服务器-第三篇 IIS中三个核心组件的讲解（下）
基于请求数的回收机制
这种基于请求数量回收的机制非常的好理解：当我们的应用程序收到的请求数量达到了一个阀值之后，就开始对应用程序池中的工作进程使用的资源进行回收，设置的方法和之前讲述的基于时间的基本类似，如图：
其实很多的时候，引起这种回收机制的原因都是应用程序已经无法处理过多的请求，导致了请求处理失败，而不得不开始运行这种回收机制。
基于内存使用的回收机制
应用程序池的回收是可以通过它所使用的内存来设置的，可以通过设置它已经使用的内存和它的虚拟内存两个方面来决定何时进行回收，大致的情况如下图：
我们使用基于内存的工作进程回收机制可以在一定的程度上面防止内存泄露或者内存过度分配的情况。同时，有一个需要清楚的的就是：很多的时候，我们的Web应用程序的性能在很大的程度上来依赖缓存，特别是在ASP.NET中使用它的缓存API的时候，我们要非常的清楚这些问题。
缓存数据空间的大小不是无限制的，它的大小是可以配置的，并且有可能出现这样的一种情况：数据在前一秒缓存进入，下一秒在使用的时候缓存的数据就没有了，可能就会导致“找不到对象“等问题，这个时候，原因就是设置的缓存空间大小已经达到了设置值，导致了工作进程回收，使得数据全部丢掉。更多的关于这个方面的讲述，可以参看我的另外的一篇文章：使用缓存的9大误区(上)
另外，设置基于内存使用的回收机制，可以让回收机制“监控“内存的时候，防止之前所说的内存泄露等情况。
说了这么多，那么我们就来看看如何来设置基于内存的回收机制。
专用内存使用情况（Private bytes）
这个设置可以限制在一个工作进程被回收之前可以使用的专用的不共享的内存的大小。其实说到这里，估计有些朋友又开始不明白了，因为这已经涉及到了Window内存管理的一些知识，大家可以参看这篇文章：window内存管理知识普及 。
注：可以说Window内存，进程调度等知识都是性能优化过程中需要掌握的基础，其实现在很多的开发人员是完全不懂这些东西，仅仅只是知道C#语法，然后使用基本的语法规程编程，如果真是这样，技术很难提升到很高的层面。
在IIS6中，这个设置在应用程序“属性“的“回收“选下卡中，被称之为“最大使用的内存“，单位是Mb，如下：
在IIS7中就称之为“专用内存”（其实也是内核模式可使用的内存数量），单位为Kb。
这个值的设置对ASP.NET应用中的缓存和Session使用至关重要。如果这个值设置的太小，同时我们的应用程序又是非常大的依赖缓存，那么，就会导致工作进程频繁的被回收，很多的在进程中保存的数据就会丢失，后果可想而知。
在ASP.NET2.0以后，缓存机制通过使用缓存剪裁策略来避免工作进程回收。什么意思呢？
就是，缓存机制会根据一些策略（例如，最近最少使用算法等）来将缓存中的一些数据移除，将空闲的位置让给别的数据，从而避免缓存空间使用过大，从而避免了内存的使用太多而达到回收的阀值。我们可以在web.config中使用privateBytesLimit设置来配置缓存裁剪的级别，如下：
下面我们就看看在默认的情况下，何时出现缓存剪裁的问题：
|
用户模式内存大小 | ||
|
<=2GB |
>2GB(32位的操作系统) |
>2GB(64位操作系统) |
|
60%*物理内存或者800Mb |
60%*物理内存或者800Mb |
60%*物理内存或者1TB |
上面的表格比较简单，我这里只是稍微的讲述一下（以用户模式内存小于2GB为例子）：如果操作系统中进程的用户模式的内存小于2GB，那么privateBytesLimit的值就会是：60%*物理内存（例如，我们配置的内存条的大小为4GB），如果配置的物理内存条的大小实太小了，例如1GB，那么此时60%*1GB=600Mb，此时privateBytesLimit就不会按照这个来设置值，而是直接取800Mb。
同时，除了设置privateBytesLimit的固定值之外，我们还可以按照比例来设置，使用percentagePhysicalMemoryUsedLimit来设置当内存使用多少之后就开始对缓存进程裁剪，这是一个动态的过程，它可以自行计算。另外，这个值也可以有效的减少.NET垃圾回收机制的运行，提升性能。
虚拟内存使用情况（Virtual bytes）
在这里，我就没有必要介绍虚拟内存的概念了。关于虚拟内存的问题也是非常的难以诊断和发现的，虚拟内存的问题主要就是碎片的问题。
当进程在运行的时候，它是由一个最大的虚拟内存大小的，例如，在Win32的操作系统中，就是4GB，用户模式与内核模式各是2GB（在没有使用/3GP的情况下）。当进程中的程序需要内存的时候，虚拟内存管理器会去分配一个空间，久而久之就可能导致虚拟内存产生很多的碎片，导致后续的内存分配无法进行，而产生”Out Of Memory”的问题。
其实，我们也没用非常好的办法来避免这个问题，但是可以通过一些经验来缓解，例如，我们可以设置当虚拟内存空间使用了70%的时候就启动回收，同时，我们也可以通过监视Process/Virtual Bytes这个性能计速器来分析数据。
系列文章链接：
IIS负载均衡-Application Request Route详解第一篇： ARR介绍
IIS负载均衡-Application Request Route详解第二篇：创建与配置Server Farm
IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡（上）
IIS负载均衡-Application Request Route详解第三篇：使用ARR进行Http请求的负载均衡（下）
IIS负载均衡-Application Request Route详解第四篇：使用ARR实现三层部署架构
负载均衡原理与实践详解 第三篇 服务器负载均衡的基本概念-网络基础
负载均衡原理与实践详解 第九篇 服务器负载均衡技术进阶-会话保持（上）
负载均衡原理与实践详解 第十篇 服务器负载均衡技术进阶-会话保持（中）
负载均衡原理与实践详解 第十一篇 服务器负载均衡技术进阶-会话保持（下） 之：延迟绑定
