怎样提高IIS服务器性能，加快服务器速度

1、应该分配和释放多个对象

你应该尽量避免过量分配内存，因为内存分配可能是代价高昂的。释放内存块可能更昂贵，因为大多数分配算符总是企图连接临近的已释放的内存块成为更大的块。直到Windows NT 40 service pack 40，在多线程处理中，系统堆通常都运行得很糟。堆被一个全局锁保护，并且在多处理器系统上是不可扩展的。

2不应该考虑使用处理器高速缓存

大多数人都知道由虚拟内存子系统导致的hard 页错误代价很高，最好避免。但是许多人认为其他内存访问方法没有什么区别。自从80486以后，这一观点就不对了。现代的CPUs比RAM要快得多，RAM至少需要两级内存缓存 ，高速L1 缓存能保存8KB数据和8KB指令，而较慢的L2 缓存能保存几百KB的数据和代码，这些数据和代码混合在一起。L1 缓存中内存区域的一个引用需要一个时钟周期，L2 缓存的引用需要4到7个时钟周期，而主内存的引用需要许多个处理器时钟周期。后一数字不久将会超过100个时钟周期。在许多方面，缓存像一个小型的，高速的，虚拟内存系统。

至于和缓存有关的基本内存单元不是字节而是缓存列。Pentium 缓存列有32个字节宽。Alpha 缓存列有64个字节宽。这意味着在L1 缓存中只有512个slot给代码和数据。如果多个数据一起使用（时间位置）而并不存储在一起（空间位置），性能会很差。数组的空间位置很好，而相互连接的列表和其他基于指针的数据结构的位置往往很差。

把数据打包到同一个缓存列中通常会有利于提高性能，但是它也会破坏多处理器系统的性能。内存子系统很难协调处理器间的缓存。如果一个被所有处理器使用的只读数据，和一个由一个处理器使用并频繁更新的数据共享一个缓存 列，那么缓存将会花费很长时间更新这个缓存列的拷贝。这个Ping-Pong高速游戏通常被称为"缓存 sloshing"。如果只读数据在一个不同的缓存 列中，就可以避免sloshing。

对代码进行空间优化比进行速度优化效率更高。代码越少，代码所占的页也越少，这样需要的运行设置和产生的页错误也会更少，同时占据的缓存 列也会更少。然而，某些核心函数应该进行速度优化。可以利用profiler去识别这些函数。

3决不要缓存频繁使用的数据。

软件缓存可以被各种应用程序使用。当一个计算代价很高时，你会保存结果的一个拷贝。这是一个典型的时空折中方法：牺牲一些存储空间以节省时间。如果做得好，这种方法可能非常有效。

你必须正确地进行缓存。如果缓存了错误数据，就会浪费存储空间。如果缓存得太多，其他操作可以使用的内存将会很少。如果缓存得太少，效率又会很低，因为你必须重新计算被缓存 遗漏的数据。如果将时间敏感数据缓存得时间过长，这些数据将会过时。一般，服务器更关心的是速度而不是空间，所以他们要比桌面系统进行更多的缓存。一定要定期去除不用的缓存，否则将会有运行设置问题。

4应该创建多个线程，越多越好。

调整服务器中起作用的线程数目是很重要的。如果线程是I/O-bound的，将会花费很多时间用来等待I/O的完成-一个被阻塞的线程就是一个不做任何有用工作的线程。加入额外的线程可以增加通量，但是加入过多的线程将会降低服务器的性能，因为上下文交换将会成为一个重大的overhead。上下文交换速度应该低的原因有三个：上下文交换是单纯的overhead，对应用程序的工作没有任何益处；上下文交换用尽了宝贵的时钟周期；最糟的是，上下文交换将处理器的缓存填满了没用的数据，替换这些数据是代价高昂的。

有很多事情是依靠你的线程化结构的。每个客户端一个线程是绝对不合适的。因为对于大量用户端，它的扩展性不好。上下文交换变得难以忍受，Windows NT用尽了资源。线程池模型会工作得更好，在这种方法中一个工人线程池将处理一条请求列，因为Windows 2000提供了相应的APIs，如QueueUserWorkItem。

5应该对数据结构使用全局锁

使数据线程安全的最简单方法是把它套上一把大锁。为简单起见，所有的东西都用同一把锁。这种方法会有一个问题：序列化。为了得到锁，每一个要处理数据的线程都必须排队等候。如果线程被一把锁阻塞，它没有在做任何有用的事。当服务器的负载较轻时，这个问题并不常见，因为一次可能只有一个线程需要锁。在负载很重的情况下，对锁的激烈争夺可能就会成为一个大问题。

设想在多车道高速公路上发生了一个意外事故，这条高速公路上的所有车辆都被转向一条狭窄的道路。如果车辆很少，这一转换对交通流的速率的影响可以忽略。如果车辆很多，当车辆慢慢并入那条单通道时，交通阻塞会延伸几英里。

有几种技术能够减少锁竞争。

· 不要过分保护，也就是说，不是非常必要不要锁住数据。只有需要时才去持有锁，而且时间不要过长。不要在大段代码周围或频繁执行的代码中没必要地使用锁，这一点很重要。

· 对数据进行分割，使它能够用一套独立的锁保护。例如，一个符号表可以按标识符的第一个字母分割，这样在修改名字以Q开头的符号的值时，就不会去读名字以H开头的符号的值。

· 使用APIs的Interlocked 系列（InterlockedIncrement，InterlockedCompareExchangePointer等）自动修改数据而不需要锁。

· 当数据不是经常被修改时可以使用多读者/单作者（multi-reader/single-writer）锁。你将获得更好的并发性，尽管锁操作的代价将更高并且你可能会冒饿死作者的危险。

· 在关键部分使用循环计数器。参见Windows NT 40 service pack 3中的SetCriticalSectionSpinCount API。

· 如果你不能得到锁，使用TryEnterCriticalSection并做一些其他的有用的工作。

高竞争导致serialization，serialization导致降低CPU的利用率，这促使用户加入更多的线程，结果事情变得更糟。

6不必注意多处理器机器

你的代码在多处理器系统上比在单处理器系统上运行得还要糟，这可能是件令人恶心的事。一个很自然的想法是，在一个N维系统上运行N次会更好。性能很差的原因是竞争：锁竞争，总线竞争，和/或缓存列竞争。处理器都在是争夺共享资源的所有权，而不是做更多的工作。

如果你一定要编写多线程应用程序的话，你应该在多处理器盒上对你的应用程序进行强度测试和性能测试。单处理器系统通过时间分片地执行线程而提供一个并发性的假象。多处理器盒具有真正的并发性，竞争环境和竞争更容易发生。

7应该始终使用模块化调用；他们很有趣。

利用同步模块化调用来执行I/O操作对大多数桌面应用程序来说是合适的。但是，他们不是使用服务器上的CPU（s）的好方法。I/O操作要花费上百万个时钟周期来完成，这些时钟周期本来可以被更好地利用。利用异步I/O你能得到显著提高的用户请求率和I/O通量，不过增加了额外的复杂性。

如果你有需要花费很长时间的模块化调用或I/O操作，你应该考调拨多少资源给他们。你想使用所有的线程还是有个限制？一般地，使用有限的几个线程要好些。构建一个小的线程池和队列，利用队列来安排线程的工作完成模块化调用。这样，其他线程就可以拾取和处理你的非模块化的请求。

8不要进行测量

当你能够测量你所谈论的事情并用数字表达它时，这就表示你对他有了一定的了解；但是如果你不能用数字表达时，你的知识是贫瘠的不能令人满意的；这可能是知识的开始，但这时你简直不可能将你的思想提高到科学的水平。

- Lord Kelvin (William Thomson)

如果不测量你就不能了解应用程序的特性。你在黑暗中摸索，一半是靠猜测。如果不识别性能问题，你就不能做任何改进或做出工作量计划。

测量包括黑匣子测量和profiling。黑匣子测量的意思是收集由性能计数器（内存使用，上下文交换，CPU利用等）和外部检测工具（通量，反映时间等）所显示的数据。为了profile你的代码，你编译代码的一个工具版，然后在各种条件下运行它，并收集关于执行时间和过程调用频率的统计数据。

测量如果不用于分析的话就一点用都没有。测量将不仅告诉你有问题，而且甚至能帮助你找到问题发生在哪，但它不能告诉你为什么会有问题。对问题进行分析以便你能正确地改正他们。要从根本上解决问题而不是停留在表面现象。

当你进行改动后，要重新测量。你要知道你的改动是否有效。改动也可能会暴露其他性能问题，测量-分析-改正-再测量的循环就会重新开始。你也必须要有规律地进行测量，以便发现性能衰退问题。

9应该使用单一用户，单一请求的测试方法。

书写ASP和ISAPI应用程序的一个通病是只用一个浏览器去测试应用程序。当他们在Internet上应用他们的程序时，他们才发现他们的应用程序不能处理高负载，并且通量和反应时间另人可怜。

用一个浏览器测试是必要的但是不够的。如果浏览器反应得不够快，你就知道你有麻烦了。但即使它在使用一个浏览器时很快，你也不知道它处理负载的能力如何。如果十几个用户同时请求会发生什么事？一百个呢？你的应用程序能容忍什么样的通量？它能提供什么样的反应时间？在轻载时这些数字会怎样？中等负载呢？重载呢？在多处理器机器上你的应用程序会如何？对你的应用程序进行强度测试，这对于找出bugs发现性能问题来说是基本的。

类似的负载测试考虑适用于所有的服务器应用程序。

10不应使用实际环境。

人们往往只在几个特定的，人工的环境（如下benchmarks）下调整应用程序。选择和实际情况相对应的各种情况，并为针对各种操作进行优化，这一点很重要。如果你不这样做，你的用户和评论家一定会这样做，并且他们将依此来评判你的应用程序的好坏。

1没有更多的服务器，而是这个服务器除了搭配数据库、集中采集器(就是数据解析、告警、存储的程序)，还要支持30w点的北向接口(SNMP)，在程序没有优化之前CPU常年占用80%以上。因为项目要求要使用双机热备，为了省事，减少不必要的麻烦，我们把相关的服务放在一起，以便能够充分利用HA的特性（外部购买的HA系统)

2系统数据正确性要求极其变态，要求从底层采集系统到最上层的监控系统，一条数据都不能差

我们的系统架构如下，可以看到，其中数据库压力非常之大，尤其在LevelA节点：

3硬件配置如下：

CPU：英特尔® 至强® 处理器 E5-2609 (4核, 240GHz, 10MB, 64 GT/s)

内存：4GB (2x2GB) DDR3 RDIMM Memory, 1333MHz,ECC

硬盘：500GB 7200 RPM 35'' SATA3 硬盘，Raid5

4数据库版本

采用的是SQLServer2012标准版，HP提供的正版软件，缺少很多企业版的NB功能。

写入瓶颈

很多时候关心的是优化SELECT 查询，因为它们是最常用的查询，而且确定怎样优化它们并不总是直截了当。相对来说，将数据装入数据库是直截了当的。然而，也存在可用来改善数据装载操作效率的策略，其基本原理如下：

成批装载较单行装载更快，因为在装载每个记录后，不需要刷新索引高速缓存；可在成批记录装入后才刷新。

在表无索引时装载比索引后装载更快。如果有索引，不仅必须增加记录到数据文件，而且还要修改每个索引以反映增加了的新记录。

较短的SQL 语句比较长的SQL 语句要快，因为它们涉及服务器方的分析较少，而且还因为将它们通过网络从客户机发送到服务器更快。这些因素中有一些似乎微不足道（特别是最后一个因素），但如果要装载大量的数据，即使是很小的因素也会产生很大的不同结果。我们可以利用上述的一般原理推导出几个关于如何最快地装载数据的实际结论：

LOAD DATA（包括其所有形式）比INSERT 效率高，因为其成批装载行。索引刷新较少，并且服务器只需分析和解释一条语句而不是几条语句。

LOAD DATA 比LOAD DATA LOCAL 效率更高。利用LOAD DATA，文件必须定位在服务器上，而且必须具有FILE 权限，但服务器可从磁盘直接读取文件。利用LOAD DATA LOCAL，客户机读取文件并将其通过网络发送给服务器，这样做很慢。

如果必须使用INSERT，应该利用允许在单个语句中指定多行的形式，例如：

可在语句中指定的行越多越好。这样会减少所需的语句数目，降低索引刷新量。如果使用mysqldump 生成数据库备份文件，应该使用--extended-insert 选项，使转储文件包含多行INSERT 语句。还可以使用- - o p t（优化） ，它启用--extended-insert 选项。反之，应该避免使用mysqldump 的--complete-insert 选项；此选项会导致INSERT 语句为单行，执行时间更长，比不用--complete-insert 选项生成的语句需要更多的分析。

使用压缩了的客户机/服务器协议以减少网络数据流量。对于大多数MySQL客户机，可以用--compress 命令行选项来指定。它一般只用于较慢的网络，因为压缩需要占用大量的处理器时间。

让MySQL插入缺省值；不要在INSERT 语句中指定将以任意方式赋予缺省值的列。平均来说，这样做语句会更短，能减少通过网络传送给服务器的字符数。此外，语句包含的值较少，服务器所进行的分析和转换就会较少。

如果表是索引的，则可利用批量插入（ LOAD DATA 或多行的INSERT 语句）来减少索引的开销。这样会最小化索引更新的影响，因为索引只需要在所有行处理过时才进行刷新，而不是在每行处理后就刷新。

如果需要将大量数据装入一个新表，应该创建该表且在未索引时装载，装载数据后才创建索引，这样做较快。一次创建索引（而不是每行修改一次索引）较快。

如果在装载之前删除或禁用索引，装入数据后再重新创建或启用索引可能使装载更快。如果想对数据装载使用删除或禁用策略，一定要做一些实验，看这样做是否值得（如果将少量数据装入一个大表中，重建和索引所花费的时间可能比装载数据的时间还要长）。

可用DROP INDEX 和CREATE INDEX 来删除和重建索引。另一种可供选择的方法是利用myisamchk 或isamchk 禁用和启用索引。这需要在MySQL服务器主机上有一个帐户，并对表文件有写入权。为了禁用表索引，可进入相应的数据库目录，执行下列命令之一：

对具有MYI 扩展名的索引文件的MyISAM 表使用myisamchk，对具有ISM 扩展名的索引文件的ISAM 表使用isamchk。在向表中装入数据后，按如下激活索引：

如果决定使用索引禁用和激活，应该使用第13章中介绍的表修复锁定协议以阻止服务器同时更改锁（虽然此时不对表进行修复，但要对它像表修复过程一样进行修改，因此需要使用相同的锁定协议）。

上述数据装载原理也适用于与需要执行不同操作的客户机有关的固定查询。例如，一般希望避免在频繁更新的表上长时间运行SELECT 查询。长时间运行SELECT 查询会产生大量争用，并降低写入程序的性能。一种可能的解决方法为，如果执行写入的主要是INSERT 操作，那么先将记录存入一个临时表，然后定期地将这些记录加入主表中。如果需要立即访问新记录，这不是一个可行的方法。但只要能在一个较短的时间内不访问它们，就可以使用这个方法。使用临时表有两个方面的好处。首先，它减少了与主表上SELECT 查询语句的争用，因此，执行更快。其次，从临时表将记录装入主表的总时间较分别装载记录的总时间少；相应的索引高速缓存只需在每个批量装载结束时进行刷新，而不是在每行装载后刷新。这个策略的一个应用是进入Web 服务器的Web 页访问MySQL数据库。在此情形下，可能没有保证记录立即进入主表的较高权限。

如果数据并不完全是那种在系统非正常关闭事件中插入的单个记录，那么减少索引刷新的另一策略是使用MyISAM 表的DELAYED_KEY_WRITE 表创建选项（如果将MySQL用于某些数据录入工作时可能会出现这种情况）。此选项使索引高速缓存只偶尔刷新，而不是在每次插入后都要刷新。

如果希望在服务器范围内利用延迟索引刷新，只要利用--delayed-key-write 选项启动mysqld 即可。在此情形下，索引块写操作延迟到必须刷新块以便为其他索引值腾出空间为止，或延迟到执行了一个flush-tables 命令后，或延迟到该索引表关闭。

1：首先需要有非常良好的网络带宽，若有上万人同时录入数据的普通的Web信息管理系统，至少需要10M左右的网络带宽，而且网通、电信的主干网都有接入比较好，否则全国各地的网络情况都不太一样，有的城市录入数据时可能会遇到网络非常缓慢的情况，甚至到无法忍受的程度。

2：须有一台牛X的Web服务器 + 一台牛X的数据库服务器(备注接近顶配的奢侈硬件服务器非个人PC)，由于是需要录入1000万条以上数据，最好采用Oracle数据库比较理想一些，经得起考验一些。

3：需要进行适当的内存缓存优化策略，不能所有的数据库都依靠SQL数据库的方式把压力放在数据库服务器上，尽量多使用内存的方式处理数据。

4：需要一个牛X的，经得起考验的数据库访问层，因为每秒都有可能成千上万的人在访问，若是质量不良好的数据库访问组件、或者不稳定的数据库访问组件，更容易导致系统崩溃、或者占用非常庞大的内存，最后容易导致整个系统的崩溃。

5：需要优化分页存取数据功能，应为有可能会有1000万条数据，若分页读取数据的功能没能优化到最高，也很容易导致系统的崩溃，因为上万人万一在同一时间，或者接近同一时间点了查询某页数据时，那系统就真崩溃了，分页存取数据一定需要做到极致才可以。

6：需要进行数据库索引优化，有索引和没索引的性能差距有时候会是100倍，大数据量时可能会有1000倍都有可能，数据库索引优化到极致了更容易得到运行顺畅的信息管理系统。

7：严谨高效的数据库事务处理，由于高并发，并且有些单据是需要同时写入多个表，需要保证数据库的一致性，要么全部成功，要么全部失败重新录入数据，所以需要一个高效的数据库事务处理机制的配合。

8：所有的系统的操作日志、异常信息都需要完整的记录下来，当系统发生一些故障时，可以快速排查问题，对正确诊断系统发生的故障的原因做分析参考用。

9：需要经常检测系统的各项指标、例如各服务器的内存使用情况、CPU使用情况、网络带宽使用情况，高峰时的各个参数是什么情况、系统不繁忙时的情况等，若服务器快承受不了压力了，就得马上增加负载均衡的服务器，网络带宽不够了需要增加等等，总不能等系统崩溃了再去做这些事情。

10：每个页面的HTML、JS都进行优化，若某个页面多余发了100个字符的垃圾HTML代码，那1万人每天获得100次，那得占用多少网络带宽，100×100×1万个字符的多余HTML被网络上传输了，要知道接入主干网的网络资源是多么宝贵，费用是多么昂贵。

11：HTML、JS等都可以考虑用压缩模式传输，那样网络传输效率会更高一些。

12：由于全国各地上万人，会有各种各样的人，这些人也未必全是好人，可能某些人心情不好，或者其他什么的，可能就会攻击我们的软件系统破坏数据，这些也可能是由于好奇心导致的，所以系统需要有严格的权限管理控制，不应该进入的页面绝对不能进入，不应该看的数据绝对不让看，不能操作的功能绝对不让多操作，一方面防止没必要的多余的麻烦，另一方面也可以减少系统被攻击破坏的可能性。

（1）优化IT功率　　

由于IT系统最终需要供电，数据中心管理人员需要尝试降低所需IT设备的功率（称为负载有功功率）。60％的有效负载功率由服务器消耗，因此采取以下行动降低所需的能耗至关重要：　　

•清理工作负载，并消除一切不必要的负载。　　

•合并虚拟机。　　

•虚拟化更多的工作负载。　　

•继续关闭那些供电但不起作用的服务器。　　

•用较新的服务器替换旧服务器。　　

（2）优化数据中心空间　　

在服务器虚拟化出现之前所构建的数据中心可能被过度构建，以满足当时的设备需求，因此如今可以进一步减少IT设备所需的空间和更少的IT功率。　　

在构建新的数据中心时，将数据中心分解为单个模块的模块化设计是值得考虑的，这些模块可以作为更灵活有机的数据中心设计的一部分，并且不断更新升级。　　

（3）优化数据中心冷却　　

为了实现最低的能耗，数据中心管理人员应确保采用基本的数据中心冷却最佳实践：　　

•安装节能器-节能器在寒冷地区可显著降低PUE。例如，在北美的大部分地区，40％至90％的冷却可以通过能器节使用从外部进来的空气。　　

•包含设备和热量-隔离结构可容纳数据中心设备产生的最多热量，将热量从数据中心散发出去，或加热建筑物的其他部分空间。　　

•优化空调系统-优化空调系统有两种主要方式，一是使用替代的冷却源（例如空气优化器）定期关闭空调系统，二是或者持续改变电源频率，这有助于减少总的能量消耗。　　

（4）提高数据中心电源和冷却的效率　　

过时的电力输送系统，包括不间断电源（UPS），配电单元（PDU）和变压器，可能对PUE值产生负面影响。因此，可以评估当前状况，未来需求和现代替代方案。虽然这需要一定的时间和投资，但通常在PUE值改进方面和节省成本方面会带来良好的回报。　　

（5）利用DCIM工具　　

可以通过使用数据中心基础设施管理（DCIM）软件实现对能源效率的进一步改进。DCIM软件在物理IT设备的操作需求和物理设施（建筑物和环境控制）之间提供必要的联系。

对于一台服务器而言，一个非常重要的方面就是它的“可用性”，即所选服务器能满足长期稳定工作的要求，不能经常出问题。其实就等同于Sun所提出的可靠性（Reliability）。 

因为服务器所面对的是整个网络的用户，而不是单个用户，在大中型企业中，通常要求服务器是永不中断的。在一些特殊应用领域，即使没有用户使用，有些服务器也得不间断地工作，因为它必须持续地为用户提供连接服务，而不管是在上班，还是下班，也不管是工作日，还是休息、节假日。这就是要求服务器必须具备极高的稳定性的根本原因。

一般来说专门的服务器都要7X24小时不间断地工作，特别像一些大型的网络服务器，如大公司所用服务器、网站服务器，以及提供公众服务iqdeWEB服务器等更是如此。对于这些服务器来说，也许真正工作开机的次数只有一次，那就是它刚买回全面安装配置好后投入正式使用的那一次，此后，它不间断地工作，一直到彻底报废。如果动不动就出毛病，则网络不可能保持长久正常运作。为了确保服务器具有高得“可用性”，除了要求各配件质量过关外，还可采取必要的技术和配置措施，如硬件冗余、在线诊断等。

如需了解更多，请访问蛙云官网wayuncn

专业领域十余载，倾情奉献

一次沟通，终生陪伴