IIS性能优化及配置注意事项之十条规则[5篇模版]

第一篇：IIS性能优化及配置注意事项之十条规则

下面的每一条戒律都将有效地影响代码的性能和可伸缩性。换句话说，尽可能不要照着戒律去做!下面，我将解释如何破坏他们以便提高性能和可伸缩性。

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

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

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 4.0 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）下调整应用程序。选择和实际情况相对应的各种情况，并为针对各种操作进行优化，这一点很重要。如果你不这样做，你的用户和评论家一定会这样做，并且他们将依此来评判你的应用程序的好坏。

第二篇：群规及注意事项

群 规 及 群 内 注 意 事 项

建群容易守群难，群友聊天畅所言。说笑嬉闹别生气，见面招呼礼在前。心平气和聊闲事，切莫骄横出狂言。若打招呼友不语，宽容理解在心间。人人都有烦心事，莫撒恶气群里边。群内之事群里知，不得随意向外传。上线空闲欢迎你，走私私聊也坦然。

聊天内容要健康，涉及政治莫乱谈。

黄色图片杜绝发，传销广告请外边。

多来分享多交流，切莫长做潜水员。

进群需尊重群里每一位女性，如发现有群内女性投诉，情节轻微、初犯者一次口头警告。情节严重者将被提出本群，请各位注意自己的语言，谢谢合作。

群内马甲格式 “♂”此为男，“♀”此为女 列如：♂-地区-网名

♂-红光-子晨，请各位统一马甲

第三篇：SQL语句性能优化

我也做了很长时间医疗软件，也写过不少sql优化，没有详细记录下来，个人感觉下面转载的更符合医院医疗软件实际业务，很认可大部分所写的原则，固转载过来，以作借鉴。软件的根本还是在于更细更精，在于从客户的实际使用考虑问题。

性能优化原则1:永远避免困境

利用缓存把字典数据取到中间服务器或是客户端替代直接sql查询,如,门诊医生站把字典下载到客户端,减少执行次数。

一次性取数据到客户端，然后再逐条处理，而不是分次取数据，处理好一条数据再取下一条再处理。例：门诊收费取hjcfmxk例子，原来是一张处方条明细都查询一次，查询后再处理，现改为一次把所有明细都取过来，然后一条条处理

尽量减少光标，看能不能用临时表

性能优化原则2:kiss原则

对于where 条件中的左边可以利用索引的字段Keep it simple stupid，左边尽量避免用函数(substring,isnull,upper,lower)，参加计算+,-*/

例子1：select * from ZY_BRFYMXK where substring(zxrq,1,8)='20081212‘

select * from ZY_BRFYMXK where zxrq between '2008121200' and '2008121224' 例子2：

select * from zy_detail_charge where SUBSTRING(patient_id,1,10)=

substring('000005090600',1,10)这句耗时30秒以上

select * from zy_detail_charge where patient_id like substring('000005090600',1,10)+'%' 这句耗时2秒以内

性能优化原则3:尽可能利用到索引

例：select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock)where a.syxh=3 and a.yzxh=b.xh and a.fylb=0

select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock)where a.syxh=3 and a.yzxh=b.xh and a.fylb=0 and b.syxh=3

性能优化原则4:or,避而远之

对于索引字段尽力避免用or，普通字段可以用or，解决要么分解成多个sql,要么用业务规则避免，例：declare @rq1 ut_rq16,@syxh ut_syxh

select @rq1='20081201'

select @syxh=157

性能优化原则5:避免大批量数据取到前台

例： select * from ZY_BRSYK cyrq between ‘20080901’ and ‘20081201‘,对于大医院每天100多人，90天是9000条数据

性能优化原则6:事务,尽可能的短吧

所有计算、对临时表的更新都应但放在事务外，事务中最好只有更新和插入正式表操作.因为事务中产生的锁只有在commit tran是才会释放。

性能优化原则7:热表，留在最后吧

热表是频繁调用的表。如：sf_mzcfk,zy_brfymxk,bq_fyqqk.对于热表尽量放在事务最后：这样锁的时间短。大家都坚持这样，死锁的可能性就小。如果都是热表各个存储过程更新表的顺序应当一样这样可以避免死锁

性能优化原则8:创建临时表一定要避免在事务中作

如create #tempXX(…)

Select * into #tempXX from …

因为创建临时表会锁tempdb的系统表

例：生成#temp1放在事务内外，用sp_lock2 ‘’观察结果

if object_id('tempdb..#temp1','U')is not null

drop table #temp1

begin tran

select * into #temp1 from ZY_BRSYK where ryrq>'20080901‘

select * from #temp1

waitfor delay '00:00:10'

commit

性能优化原则9:大的报表查询避免与正常业务碰撞

如果没有查询服务器，那要在存储过程中限制不能操作加上如：

declare @rq1 ut_rq16,@rq2 ut_rq16,@now ut_rq16

select @rq1=convert(varchar(8),getdate(),112)+'08:00:00'

select @rq1=convert(varchar(8),getdate(),112)+'11:30:00'

select @now=convert(char(8),getdate(),112)+convert(char(8),getdate(),8)

if @now>@rq1 and @now<@rq2

begin

select '上午繁忙时间段不能作此查询'

return

end

性能优化原则10:存储过程避免大的if…else…

这个常出项在业务相同表不同的存储过程中，因为这样常到if …else …原来医技接口中很多这种存储过程，当时把门诊住院业务放在一个存储过程中。这样最大的问题是sql server会根据sql语句来compile存储，这个过程会生成优化计划，决定用那个索引。如果存储过程用到门诊表compile一下，到用到住院表是发现不对，又会compile一下，这样不停compile.compile很号时间要1-2秒，而且一个存储过成在compile是，所有调用这个存储过程的进程都要在排队等候,因为他会独占锁这个存储过程

例：usp_yjjk_getwzxxm_old.sql,后改为：

usp_yjjk_getwzxxm.sql, usp_yjjk_getwzxxm_mz.sql,usp_yjjk_getwzxxm_zy.sql

性能优化原则11:进攻是最好的防守

在普通编程语句对于数据校验总是用防守办法先判断,后再作相应处理。而在sql中先处理再判断性能会好很多。

--更新药品库存。

If exists(select 1 from YK_YKZKC WHERE idm=100 and kcsl>50)

begin

update YK_YKZKC set kcsl=kcsl-50 where idm=100

End

Else begin

rollback tran

Select ‘F库存不够’

return

end

--改为

update YK_YKZKC set kcsl=kcsl-50 where idm=100 and kcsl>50

If @@rowcount<=0

Begin

Rollbakc tran

Select ‘F库存不够’

end

--取未执行的医技项目,日表没有数据就到年表中查找

if exists(select a.* from SF_MZCFK a(nolock),SF_CFMXK b(nolock)

begin

select a.* into #temp1 from SF_MZCFK a(nolock),SF_CFMXK b(nolock)

end

else begin

select a.* into #temp1 from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)

end

--改为

Insert into #temp1 select a.*

from SF_MZCFK a(nolock),SF_CFMXK b(nolock)

If @@rowcount=0

Begin

Insert into #temp1 select a.*

from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)

end

性能优化原则12:trig最后的手段

Trig（触发器）的处理的处理机制是满足条件时就会在源语句后面加上trig中的代码进行执行。

它有两个致命的弊端：（1）不清楚有trig的人会对于执行结果感到迷惑。如常有在插入一张表如果主键是indentity的值常取用select @@identity。但如是有trig,tring中有表插入操作，这时的@@identity可能就不是想要的值。（2）trig会束缚选择。如：有一套单据主表和明细表，当明细表的金额更新时，要同步主表的金额，当程序是一条条更新明细时用trig的作法是每当更新一条明细记录时都算一处所有明细表的总金额，再去更新主表的金额。这样有多少条明细就要算多少次，好的作法是不要trig,直接在sql语句中明细更新完明后，一次性算出总金额每条单据的总金额，再更新主表的金额。

对于trig如果有其他手段就一定要避免用trig.性能优化原则13:用户说好才是真的好

1）有时sql语句性能难以优化，但用户对于系统响应速度还是不满意。这时可以从业务分析处理。

如：我们退费模块录入发票号原来是用fph like ‘XXX%’。用户报怨慢，后来改为先用fph=‘XXX’来查，如查不到再fph like ‘XXX%’。这样在绝大部情况下速度都非常快，同时也满足小部分情况下模糊查询的需求。

如：我们的程序要查日表和年表。如果通过日表union表视图去查会非常慢，性能也难以优化。程序改为普通情况下不查年表，用户勾上年表标志时才查年表。

（2）查询统计很多数据时间比较长，就以查询完一部分数据后可以显示这部分数据或是用提示，这样用户清楚系统在作事情也知道大概进度。这样情绪上会好很多。

（3）查询模块常有一进入时也默认一个查询，如果性能好，查询又合用户心意，这种设计非常好，如果性能不好，那就不是好的设计。用户对于进入都困难的模块是没有好感的。

（4）有户的耐心与查询出的记录成正比。用户痛恨等待很久却没有查询出记录。

对于非常慢的查询，如果有些子查询非常快可以先作这样查询以避免查询很久却没有数据出来的情况。如：按病历号查在院病人所有费有明细，可以先查一下这个病历是不是有对应病人。

实战技巧1:用exists、in代替distinct

Distinct实际上是先收集再删除这样两步都耗资源。

Exists,in会隐式过滤掉重复的记录

例查自2009年以来有金额大于100的药品的病人

select distinct a.blh,a.hzxm from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock)where a.patid=b.patid and b.syxh=c.syxh and c.zxrq>'2009' and c.zje>100--改为

select a.blh,a.hzxm from ZY_BRXXK a where exists(select 1 from ZY_BRSYK

b(nolock),ZY_BRFYMXK c(nolock)where a.patid=b.patid and b.syxh=c.syxh and

c.zxrq>'2009'and c.zje>100)

实战技巧2:缩短union

select …from A,B,C,D,E1

where(E1的条件)

and(其他表联接条件)

union

select …from A,B,C,D,E2

where(E2的条件)

and(其他表接接条件)

改为

select …from A,B,C,D,(select...from E1where(E1条件)

union

select …from E2where(E2条件))E where(其他条件)

当涉及ABCD表部分耗资源而E1,E2不耗资源时是这样，如果反过来则改后的性能不一定好。查2009年4月后入院的在院病人在2905病区发生的所有费用明细

select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw

select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw

from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YK_YPCDMLK d where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm

union all

select a.hzxm,b.cyrq,d.name,d.xmgg,c.ypsl/c.dwxs ypsl, c.ypdw

from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YY_SFXXMK d where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.ypdm=d.id and c.idm=0

--改为

select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw

from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),(select ypmc,ypgg,ypdm,idm idm from YK_YPCDMLK union select name,xmgg,id,0 from YY_SFXXMK)d

where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm and c.ypdm=d.ypdm

实战技巧3:合并sql

把表和where条件类似的两个或是多个sql合并为一个sql.--查2009年以后的普通、急诊、专家挂号人数

declare @ptghs int,@jzghs int,@zjghs int

select @ptghs=0,@jzghs=0,@zjghs=0

select @ptghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=0

select @jzghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=1

select @zjghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=2

select @ptghs,@jzghs,@zjghs

--改为

select @ptghs=0,@jzghs=0,@zjghs=0

select @ptghs=sum(case when ghlb=0 then 1 else 0 end),@jzghs=sum(case when ghlb=1 then 1 else 0 end), @zjghs=sum(case when ghlb=2 then 1 else 0 end)

from GH_GHZDK where ghrq>'2009'

select @ptghs,@jzghs,@zjghs

实战技巧4:去掉游标

把游标当作编程语言的for,do---while的方式，很多情况下都可以去掉,如果光标中间sql语句只有一条一般都是可以去掉光标改为一句sql。

--查当天出院出院日期在2009年4月1到9日间病人的zfdj,zfje置为0

declare @syxh ut_syxh

declare cur1 cursor for select syxh from ZY_BRSYK where cyrq>='20090401' and cyrq<'20090410'

open cur1

fetch cur1 into @syxh

while @@fetch_status=0

begin

fetch cur1 into @syxh

end

close cur1

deallocate cur1

--改为

update ZY_BRFYMXK set zfdj=0,zfje=0

from ZY_BRFYMXK a,ZY_BRSYK b

where a.syxh=b.syxh and b.cyrq>='20090401' and b.cyrq<'20090410'

实战技巧5:取代count

利用内部函数代替

declare @count int

select * into #tmep1 from ZY_BRFYMXK WHERE zxrq>'200901'

select @count=@@rowcount—可以得到count值

select @count

select @count=count(*)from #tmep1—可以被取代

select @count

利用exists而不count判断有没有记录

declare @count int

Select @count=count(1)from ZY_BRFYMXK WHERE zxrq>'2009‘

If @count>0 … else ….--改为

If exists(Select 1 from ZY_BRFYMXK WHERE zxrq>'2009’)… else ….

第四篇：实验一 静态网页制作与IIS配置

实验一 静态网页制作与IIS配置

1实验目的1．了解网站开发的基本流程，掌握网站结构搭建的原则，网页设计基本原则。

2．掌握各种静态页面制作方法，利用相关网页制作软件制作各种静态页面。

3．基本掌握IIS Web服务器的安装、配置与简单使用的方法。

2、实验环境

微型计算机，windows xp操作系统，DreamWeaver 和FrontPage软件。

3实验内容

设计并制作出5-7个页面的个人站点，要求主题鲜明，内容健康，积极向上，新颖有创意。

【基本要求】

（1）首先选定主题，设计好网站结构，及各页面图样，然后组织各页面内容，再进行开发制作。

（2）安装与配置IIS。

（3）在服务器上发布网站。

【实验要点】

（1）静态页面设计

主要从页面布局，网站整体风格，网站结构搭建等方面入手，最好在完成网站策划设计书后，再着手进行具体页面设计。

（2）IIS配置

1、在winxp的系统下,打开控制面板->添加删除程序->添加/删除windows组件->选择IIS。

2、在IIS上发布个人网站。

3、测试发布的网站。

【思考题】

（1）参考网络中优秀的个人网站，谈谈如何改进自己网站的页面布局，网站整体风格等？

（2）怎么在windows2003或Vista操作系统上配置IIS服务器？

第五篇：标准溶液配置注意事项

溶液配制通则

5.1分析实验所用的溶液应用纯水配制，容器应用纯水洗三次以上。特殊要求的溶液应事先作纯水的空白值检验。

5.2所用试剂的纯度应为分析纯或分析纯以上，根据不同的工作要求合理选用相应级别的试剂。

5.3为保证试剂不受污染，应用清洁的牛角勺从试剂瓶中取出，绝不可用手抓取。

5.4试剂结块可用洁净的粗玻璃棒或瓷药铲将其捣碎后取出。

5.5打开易挥发的试剂瓶塞时不可把瓶口对准脸部。夏季由于室温高，试剂瓶中很易冲出气液，最好把瓶子在冷水中浸一段时间再打开瓶塞。放出有毒，有味气体的瓶子应该用蜡封口。

5.6若嗅试剂气味，可将瓶口远离鼻子，用手在试剂瓶上方扇动，绝不可用舌头品尝试剂

5.7所用天平的砝码，滴定管，容量瓶及移液管均需定期校正。

5.8配制硫酸，磷酸，盐酸等溶液时，都应把酸倒入水中。对于溶解时放热较多的试剂，不可在试剂瓶中配制，以免炸裂。

5.9配制硫酸溶液时，应将浓硫酸分为小份慢慢倒入水中，边加边搅拌，必要时以冷水冷却烧杯外壁。溶解氢氧化钠，氢氧化钾等时，大量放热，也必须在耐热容器中进行。

5.10 用有机溶剂配制溶液时，有时有机物溶解较慢，应不时搅拌，可以在热水浴中温热溶液，不可直接加热。易燃溶剂使用时要远离明火。几乎所有的有机溶剂都有毒，应在通风柜内操作，为避免有机溶剂不必要的蒸发，烧杯应加盖。

5.11不能用手接触腐蚀性及有剧毒的溶液，剧毒废液应作解毒处理，不可直接倒入下水道。

5.12 溶液要用带塞的试剂瓶盛装，见光易分解的溶液要装于棕色瓶中，挥发性试剂例如用有机溶剂配制的溶液，瓶塞要严密，见空气易变质及放出腐蚀性气体的溶液也要盖紧，长期存放时要用蜡封住。浓碱液应用塑料瓶装，如装在玻璃瓶中，要用橡皮塞塞紧，不能用玻璃磨口塞。

5.13 每瓶试剂溶液必须有标明名称、规格、浓度、配制日期、有效期及配制人的标签。

6.1.应用纯水配制.(应符合GB-6682《实验室用水规格》中三级水的规定。

6.2除高氯酸外，均指20℃时的浓度。在标准滴定溶液标定，直接制备和使用时若温度有差异，应要求补正。标准滴定溶液标定，直接制备和使用时所用分析天平、砝码、滴定管、容量瓶、单标线吸管等均须定期校正。

6.3标定时所用的基准试剂为容量分析工作基准试剂；制备标准溶液时所用的试剂为分析纯以上试剂。

6.4标准溶液的浓度为标准温度20℃时的浓度,温度有差异需补正.6.5.“标定”或“比较”标准溶液浓度时,平行试验不得少于8次,俩人各做4平行,4次平行测定结果的极差与平行值之比不得大于0.1%.结果取平均值,浓度取四位有效数字.6.6.“标定”和“比较”法测浓度时,两种方法测得的浓度之差不得大于0.2%,以标定结果为准.6.7.滴定分析用标液在常温(15-25C)下,保存时间一般不超过2个月.当溶液出现浑浊、沉淀、颜色变化等现象时，应重新配制。

6.8当配制的标准溶液浓度与欲配制的浓度不一致时，可作调整，调整计算公式如下：

（1）当C已配>C欲配时：V欲加水C已配-C欲配C欲配

C欲配-C已配V配制溶液剩余体积（2）当C已配

6.8制备的标准溶液浓度与规定浓度相对误差不大于5%。浓度值取四位有效数字。

6.9配制浓度等于或低于0.02mol/L标准溶液时，应于临用前将浓度高的标准溶液用煮沸并冷却的水稀释，必要时应重新标定。

6.10碘量法反应时，溶液的温度不能过高，一般在15～20℃之间进行滴定。

6.12在标定和使用标准滴定溶液时，滴定速度一般应保持在６ｍｌ／ｍｉｎ－８ｍｌ／ｍｉｎ

6.13称量工作基准试剂的质量的数值小于等于０.５ｇ时，按精确至0.00001ｇ称量；数值大于０.５ｇ时按精确至0.0001ｇ称量。

6.14本标准使用工作基准试剂标定标准滴定溶液的浓度。当对标准滴定溶液浓度值的准确度有更高要求时，可使用二级纯度标准物质代替工作基准试剂进行标定或直接制备并计算标准滴定溶液浓度值时，将其质量分数代入计算式中。

6.15标准滴定溶液的浓度小于或等于０.０２ｍｏｌ／Ｌ时，应于临用前将浓度高的标准滴定溶液用煮沸并冷却的水稀释，必要时重新标定。

6.16储存标准滴定溶液的容器，其材料不应与溶液起理化作用。壁厚最薄出不小于０.５ｍｍ。

注：标准溶液是分析的重要依据。一定严格按照要求配置及标定。