导读:
Object Pooling
COM+的新功能之一就是Object Pooling(对象缓冲),该技术允许对象创建在缓冲池中以便重用对象,它减少了例示对象所花费的总时间。Windows NT4中不包含该技术,可以在通过Component Services将基于VB或VC组件添加COM+应用的时候试验该技术。你会发现基于VB的组件是不能使用该技术的,而任何基于VC的组件可以使用该技术。
Visual Basic 组件不能被缓冲是因为它们是单元线程的(apartment threaded),而对象缓冲技术要求组件必须能够运行在Neutral-threaded或者是Multithreased-apartment(MTA-多线程单元)。
Visual C++创建的组件可以被标记为Both-threaded,这意味着它们运行在MTA的模式下,因此符合对象缓冲的线程要求。但是,如果组件创建为MTS组件,它们就不能支持对象缓冲。对象缓冲技术需要组件支持聚合,而MTS要求组件不支持聚合。事实上使用ATL创建MTS的时候,在组件的头文件中就放置了防止组件聚合的宏(Marco)。
DECLARE_NOT_AGGREGATABLE(CComponent)
对象缓冲技术的另一个要求是任何由组件分配的资源必须由组件处理(组件不维护客户端状态),这意味着附加的工作以确保组件被Windows 2000定义为可缓冲。你可能要做些工作才能使Visual C++的组件使用对象缓冲技术,而就不用考虑如何让Visual Basic组件使用该技术了,至少目前如此。
不管怎么说,你的组件仍旧拥有在NT4下的功能,这才是我们将组件和相关的ASP应用迁移Windows 2000最关心的。
一旦设置好ASP开发环境并迁移成功ASP组件和MTS包,就该开始进行单元测试阶段。现在让我们看看Windows 2000中ASP本身的改变。
ASP Object Model的差异
IIS 5.0中的ASP对象模型已经发生了变化,添加一些新的方法,也改变了某些已有方法和属性的表现。值得注意的变化是ASP缓存现在是默认的选项,而以前默认是不进行缓存。由于这个改变,所有的ASP脚本都会在页面内容返回之前处理完毕。默认的缓存可能会影响到现有ASP应用,尤其是那些较长的数据库查询和时间敏感的操作。
举例来说,可以创建一个包含200万次循环的ASP页面,并在循环中将循环变量设为0,显然这段代码毫无意义,它主要是为了能够产生足够长时间的进程以引起注意。然后在循环的前面和后面添加Response.Write语句。
<%
Response.Write "
Dim i, j
For i = 1 To 2000000
j = 0
Next
Response.Write "
%>
先暂时关闭ASP缓存选项。操作如下:
对于站点:属性>Home Directory>Configuration>App Options
对于虚路径:属性>Directory>Configuration>App Options
第一个头会在循环结束前返回到客户端,而第二个头会在循环后返回(可能要花上些时候)。当重新开启缓存选项视。循环结束前是不会返回任何内容的。
如果ASP应用涉及长数据库查询或其它处理,而你需要使用输出告知客户端正在处理,可以关闭受影响的ASP应用的缓存功能,也可以使用Response对象修改受影响的页面使其禁止缓存,或者在执行长进程前刷新(Flush)缓存。
如果原来ASP应用已经在使用缓存,不必改变任何的代码,多余的缓存设置并不会影响应用程序,除了会耗费些处理脚本的时间:
<% Response.Buffer = True %>
另一个可能对ASP应用产生影响的是IsConnected属性现在会做出正确的反映而不管ASP页面是否返回内容,而以前,如果ASP页面不返回内容该属性不会正常的工作。幸运的是尽管你可能在以前的应用中使用了该属性,也可能为以前的缺陷编写了一些代码补救,原有的代码仍然可以很好的工作于IIS 5.0的环境中。
IIS 5.0中的ASP添加了一些新的方法,如Server.Execute 和Server.Transfer方法,Session和Application的Collection集合的Remove,RemoveAll方法以及新的对象ASPError。使人感兴趣的是,这些改进并不会对迁移应用造成影响。但是,一旦成功的迁移了应用,要校验这些增强的选项,尤其是Server.Transfer方法。该方法会将客户端传递到新的ASP页面中而不返回浏览器。它同时将所有的请求(Request)信息传递过去,也包括了没有完成的事务。这是诸多改进中最令人兴奋的事情。
进行完单元测试以及必要的修改工作以确保ASP应用如原计划正常工作,就可以将它们转移到测试环境中进行兼容性测试和压力测试。
在经受了测试环境严酷的考验后,下一步也是最后一步就是将ASP应用迁移到它们真正的家中-最终生产环境。希望不要在这个时候再做什么修改了。迁移的工作完成后,打开CPU跟踪功能跟踪每一个迁移进来的程序,确保它们不会占用过多的CPU时间,有必要的话对那些新的应用使用CPU和带宽扼制功能。
最后的事情就是象在Windows NT4中一样的监视应用程序的运行状态。
总结
本文我们提供了一个多步的进程以便创建向Windows 2000迁移的计划。希望我们提供了足够详细的信息—包括设置IIS5.0、WEB安全、针对Visual Basic和Visual C++创建ASP组件开发环境、移植MTS包到COM+应用、处理ASP的不同。我们希望能够使你在面对不同的问题时能够清晰的认识到问题所在。
你会发现将ASP应用迁移到Windows 2000是无法抵抗的任务,你可以利用Windows 2000新的功能,而不需要花费太多的力气,对应用本身的影响也是极小的
本文转自
http://study.qqcf.com/web/243/29217.htm
Object Pooling
COM+的新功能之一就是Object Pooling(对象缓冲),该技术允许对象创建在缓冲池中以便重用对象,它减少了例示对象所花费的总时间。Windows NT4中不包含该技术,可以在通过Component Services将基于VB或VC组件添加COM+应用的时候试验该技术。你会发现基于VB的组件是不能使用该技术的,而任何基于VC的组件可以使用该技术。
Visual Basic 组件不能被缓冲是因为它们是单元线程的(apartment threaded),而对象缓冲技术要求组件必须能够运行在Neutral-threaded或者是Multithreased-apartment(MTA-多线程单元)。
Visual C++创建的组件可以被标记为Both-threaded,这意味着它们运行在MTA的模式下,因此符合对象缓冲的线程要求。但是,如果组件创建为MTS组件,它们就不能支持对象缓冲。对象缓冲技术需要组件支持聚合,而MTS要求组件不支持聚合。事实上使用ATL创建MTS的时候,在组件的头文件中就放置了防止组件聚合的宏(Marco)。
DECLARE_NOT_AGGREGATABLE(CComponent)
对象缓冲技术的另一个要求是任何由组件分配的资源必须由组件处理(组件不维护客户端状态),这意味着附加的工作以确保组件被Windows 2000定义为可缓冲。你可能要做些工作才能使Visual C++的组件使用对象缓冲技术,而就不用考虑如何让Visual Basic组件使用该技术了,至少目前如此。
不管怎么说,你的组件仍旧拥有在NT4下的功能,这才是我们将组件和相关的ASP应用迁移Windows 2000最关心的。
一旦设置好ASP开发环境并迁移成功ASP组件和MTS包,就该开始进行单元测试阶段。现在让我们看看Windows 2000中ASP本身的改变。
ASP Object Model的差异
IIS 5.0中的ASP对象模型已经发生了变化,添加一些新的方法,也改变了某些已有方法和属性的表现。值得注意的变化是ASP缓存现在是默认的选项,而以前默认是不进行缓存。由于这个改变,所有的ASP脚本都会在页面内容返回之前处理完毕。默认的缓存可能会影响到现有ASP应用,尤其是那些较长的数据库查询和时间敏感的操作。
举例来说,可以创建一个包含200万次循环的ASP页面,并在循环中将循环变量设为0,显然这段代码毫无意义,它主要是为了能够产生足够长时间的进程以引起注意。然后在循环的前面和后面添加Response.Write语句。
<%
Response.Write "
About to perform long loop
"Dim i, j
For i = 1 To 2000000
j = 0
Next
Response.Write "
Long loop is finished
"%>
先暂时关闭ASP缓存选项。操作如下:
对于站点:属性>Home Directory>Configuration>App Options
对于虚路径:属性>Directory>Configuration>App Options
第一个头会在循环结束前返回到客户端,而第二个头会在循环后返回(可能要花上些时候)。当重新开启缓存选项视。循环结束前是不会返回任何内容的。
如果ASP应用涉及长数据库查询或其它处理,而你需要使用输出告知客户端正在处理,可以关闭受影响的ASP应用的缓存功能,也可以使用Response对象修改受影响的页面使其禁止缓存,或者在执行长进程前刷新(Flush)缓存。
如果原来ASP应用已经在使用缓存,不必改变任何的代码,多余的缓存设置并不会影响应用程序,除了会耗费些处理脚本的时间:
<% Response.Buffer = True %>
另一个可能对ASP应用产生影响的是IsConnected属性现在会做出正确的反映而不管ASP页面是否返回内容,而以前,如果ASP页面不返回内容该属性不会正常的工作。幸运的是尽管你可能在以前的应用中使用了该属性,也可能为以前的缺陷编写了一些代码补救,原有的代码仍然可以很好的工作于IIS 5.0的环境中。
IIS 5.0中的ASP添加了一些新的方法,如Server.Execute 和Server.Transfer方法,Session和Application的Collection集合的Remove,RemoveAll方法以及新的对象ASPError。使人感兴趣的是,这些改进并不会对迁移应用造成影响。但是,一旦成功的迁移了应用,要校验这些增强的选项,尤其是Server.Transfer方法。该方法会将客户端传递到新的ASP页面中而不返回浏览器。它同时将所有的请求(Request)信息传递过去,也包括了没有完成的事务。这是诸多改进中最令人兴奋的事情。
进行完单元测试以及必要的修改工作以确保ASP应用如原计划正常工作,就可以将它们转移到测试环境中进行兼容性测试和压力测试。
在经受了测试环境严酷的考验后,下一步也是最后一步就是将ASP应用迁移到它们真正的家中-最终生产环境。希望不要在这个时候再做什么修改了。迁移的工作完成后,打开CPU跟踪功能跟踪每一个迁移进来的程序,确保它们不会占用过多的CPU时间,有必要的话对那些新的应用使用CPU和带宽扼制功能。
最后的事情就是象在Windows NT4中一样的监视应用程序的运行状态。
总结
本文我们提供了一个多步的进程以便创建向Windows 2000迁移的计划。希望我们提供了足够详细的信息—包括设置IIS5.0、WEB安全、针对Visual Basic和Visual C++创建ASP组件开发环境、移植MTS包到COM+应用、处理ASP的不同。我们希望能够使你在面对不同的问题时能够清晰的认识到问题所在。
你会发现将ASP应用迁移到Windows 2000是无法抵抗的任务,你可以利用Windows 2000新的功能,而不需要花费太多的力气,对应用本身的影响也是极小的
本文转自
http://study.qqcf.com/web/243/29217.htm