ASP网站制作之甚么才是进步ASP功能的最好挑选
缺乏可以共同遵循的行业标准，ASP还处在发展初期，大家对它的理解不同，如产品和服务标准，收费标准等，不利于行业的健康发展。功能ASP开辟职员为了在他们的计划项目中取得更好的功能和可扩大性而不休勉力。侥幸地是，有很多书本和站点在这方面供应了很好的倡议。可是这些倡议的基本都是从ASP平台事情的布局上所得出的结论，对实践取得的功能的进步没有量的丈量。因为这些倡议必要加倍庞大的编码历程并下降了编码的可读性，开辟职员就只能在看不到实践运转效果的情形下，单独权衡为了进步他们ASP使用程序的功能是不是值得支付这些价值。
本文分为两年夜部分，我将先容一些功能测试了局，匡助开辟职员来断定某一特定举动是不是不但对未来的项目来讲是值得的，而且可以对本来的项目举行更新。在第一部分我将回忆一些ASP开辟的基本性成绩。在第二部分，将触及一些最优化ADO函数，并将它们的了局与挪用VBCOM工具实行不异ADO函数的ASP页面举行对照。这些了局很让人开眼界，乃至有些时分是很使人受惊的。
在本文中，我们将回覆以下成绩：
*将ASP天生的内容写进呼应流中最无效的办法是甚么？
*是不是应当开启缓冲器？
*是不是应当思索向ASP代码中增添正文？
*是不是应当为页面明白地设置默许言语？
*假如不必要，是不是应当封闭Session形态？
*是不是应当把剧本逻辑放在子程序和函数区中？
*利用包括文件有甚么影响？
*实行毛病处置时会施加甚么样的负载？
*设置一个高低文处置是不是对功能有影响？
一切测试都是用Microsoft的Web使用程序重点工具(WAST)来举行的，这是一个收费的工具，能够在这里(http://webtool.rte.microsoft.com/)找到。我用WAST创立了一个复杂的test剧本，重复挪用上面所形貌的ASP页面测试（每一个凌驾70，000次）。反响的工夫基于均匀最初字节总工夫(TTLB),也就是从最后哀求的工夫到工具从服务器吸收最初一名数据的工夫。我们的测试服务器是一个Pentium166，内存为196MB，客户机为Pentium450，内存为256MB。你大概会想这些呆板的功能其实不算很初级，可是不要忘了，我们并非要测试服务器的容量，我们只是要测试服务器每次处置一个页面所用的工夫。测试时代这些呆板不做别的事情。WAST测试剧本、测试呈报和一切的ASP测试页面都包括在ZIP文件(http://www.asptoday.com/articles/images/20000113.zip)中，你能够本人举行回忆和测试。
将ASP天生的内容写进呼应流中最无效的办法是甚么？
利用ASP的一个最次要缘故原由是在服务器上天生静态内容。以是很分明，我们测试的出发点是断定将静态内容发送到呼应流中的最合适的体例。在多种选择中，有两个是最基础的：一是利用内联ASP标志，另外一个是利用Response.Write语句。
为测试这些选择，我们创立了一个复杂的ASP页面，个中界说了一些变量，然后将它们的值拔出表格中。固然这个页面很复杂也不是很有用，但它同意我们分别并测试一些独自的成绩。
利用ASP内联标志
第一个测试包含利用内联ASP标志<%=x%>，个中x是一个已赋值的变量。到今朝为止，这个办法是最简单实行的，而且它使页面的HTML部分坚持一种易于浏览和保护的格局。
<%OPTIONEXPLICIT
DimFirstName
DimLastName
DimMiddleInitial
DimAddress
DimCity
DimState
DimPhoneNumber
DimFaxNumber
DimEMail
DimBirthDate
FirstName="John"
MiddleInitial="Q"
LastName="Public"
Address="100MainStreet"
City="NewYork"
State="NY"
PhoneNumber="1-212-555-1234"
FaxNumber="1-212-555-1234"
EMail="john@public.com"
BirthDate="1/1/1950"
%>
<HTML>
<HEAD>
<TITLE>ResponseTest</TITLE>
</HEAD>
<BODY>
<H1>ResponseTest</H1>
<TABLE>
<tr><td><b>FirstName:</b></td><td><%=FirstName%></td></tr>
<tr><td><b>MiddleInitial:</b></td><td><%=MiddleInitial%></td></tr>
<tr><td><b>LastName:</b></td><td><%=LastName%></td></tr>
<tr><td><b>Address:</b></td><td><%=Address%></td></tr>
<tr><td><b>City:</b></td><td><%=City%></td></tr>
<tr><td><b>State:</b></td><td><%=State%></td></tr>
<tr><td><b>PhoneNumber:</b></td><td><%=PhoneNumber%></td></tr>
<tr><td><b>FaxNumber:</b></td><td><%=FaxNumber%></td></tr>
<tr><td><b>EMail:</b></td><td><%=EMail%></td></tr>
<tr><td><b>BirthDate:</b></td><td><%=BirthDate%></td></tr>
</TABLE>
</BODY>
</HTML>
/app1/response1.asp的完全代码
之前的最好（反响速率）=8.28msec/page
在HTML的每利用用Response.Write语句
很多对照好的进修文档倡议制止利用后面的那种办法。其次要来由是，在输入页面和处置页面施加反响工夫的过程当中，假如web服务器不能不在发送纯HTML和处置剧本之间举行转换，就会产生一种被称为高低文转换的成绩。年夜部分程序员一听到这里，他们的第一反响就是将原始的HTML的每行都包装在Response.Write函数中。
…
Response.Write("<html>")
Response.Write("<head>")
Response.Write("<title>ResponseTest</title>")
Response.Write("</head>")
Response.Write("<body>")
Response.Write("<h1>ResponseTest</h1>")
Response.Write("<table>")
Response.Write("<tr><td><b>FirstName:</b></td><td>"&FirstName&"</td></
tr>")
Response.Write("<tr><td><b>MiddleInitial:</b></td><td>"&MiddleInitial&"<
/td></tr>")
…
/app1/response2.asp的片断
之前的最好（反响速率）=8.28msec/page
反响工夫=8.08msec/page
差=-0.20msec(削减2.4%)
我们能够看到，利用这类办法与利用内联标志的办法比拟在功能上取得的收益十分小，这大概是由于页面给服务器装载了一年夜堆小的函数挪用。这类办法最年夜的弱点是，因为如今HTML都嵌进剧本中，以是剧本代码变得加倍冗杂，加倍难以浏览和保护。
利用包装函数
当我们试图利用Response.Write语句这类办法时，最使人悲观的发明大概就是Response.Write函数不克不及在每行的开头处安排一个CRLF。因而，当你从扫瞄器中浏览源代码时，原本安排得十分好的HTML，如今成了没有停止的一行。我想，你的下一个发明大概会更令你可怕：在Response工具中没有其姊妹函数Writeln。以是，一个很分明的反响就是为Response.Write函数创立一个包装函数，以便给每行都附加一个CRLF。
…
writeCR("<tr><td><b>FirstName:</b></td><td>"&FirstName&"</td></tr>")
…
SUBwriteCR(str)
Response.Write(str&vbCRLF)
ENDSUB
/app1/response4.asp的片断
之前的最好（反响速率）=8.08msec/page
反响工夫=10.11msec/page
差=+2.03msec(增添25.1%)
固然，因为这类办法无效地使函数挪用次数更加，其对功能的影响也很分明，因而要不吝统统价值制止。具有取笑意味的是CRLF也向反响流中为每行增添了2个字节，而这是扫瞄器不必要出现到页面上的。格局化优秀的HTML所做的统统就是让你的合作者更简单浏览你的HTML源代码并了解你的计划。
将一连的Response.Write毗连到一个独自语句中
不思索我们后面用包装函数举行的测试，下一个符合逻辑的步骤就是从独自的Response.Write语句中提掏出一切的字符串，将它们毗连到一个独自语句中，如许就削减了函数挪用的次数，极年夜地进步了页面的功能。
…
Response.Write("<html>"&_
"<head>"&_
"<title>ResponseTest</title>"&_
"</head>"&_
"<body>"&_
"<h1>ResponseTest</h1>"&_
"<table>"&_
"<tr><td><b>FirstName:</b></td><td>"&FirstName&"</td></tr>"&_
…
"<tr><td><b>BirthDate:</b></td><td>"&BirthDate&"</td></tr>"&_
"</table>"&_
"</body>"&_
"</html>")
/app1/response3.asp的片断
之前的最好（反响速率）=8.08msec/page
反响工夫=7.05msec/page
差=-1.03msec(削减12.7%)
今朝，这是最优化的设置。
将一连的Response.Write毗连到一个独自语句中，在每行开头处增添一个CRLF
思索到那些请求他们的源代码从扫瞄器中看要很地道的人，我用vbCRLF常量在后面测试中每行的开头处拔出了一些回车，然后从头运转。
…
Response.Write("<html>"&vbCRLF&_
"<head>"&vbCRLF&_
"<title>ResponseTest</title>"&vbCRLF&_
"</head>"&vbCRLF&_
…
/app1/response5.asp的片断
后面的最好（反响速率）=7.05msec/page
反响工夫=7.63msec/page
差=+0.58msec(增添8.5%)
运转的了局在功能上有一点下降，这大概是因为分外的串连和增添的字符量。
回忆和观察
夙昔面有关ASP输入的测试中能够得出一些划定规矩：
*制止内联ASP的过量利用。
*老是将一连Response.Write语句毗连进一个独自语句内。
*永久不要在Response.Write四周利用包装函数来附加CRLF。
*假如必需格局化HTML输入，间接在Response.Write语句内附加CRLF。是不是应当开启缓冲器？
经由过程剧本程序启动缓冲器
在ASP剧本的顶部包括Response.Buffer=True，IIS就会将页面的内容缓存。
<%OPTIONEXPLICIT
Response.Buffer=true
DimFirstName
…
/app1/buffer__1.asp的片断
之前的最好（反响工夫）=7.05msec/page
反响工夫=6.08msec/page
差=-0.97msec(下降13.7%)
功能失掉了极年夜进步。可是等等，还能有更好的。
经由过程服务器设置启动缓冲器
固然在IIS5.0中缓冲器是被默许启动的，可是在IIS4.0中还必需手动来启动它。这时候要找到站点的Properties对话框，在那边，从HomeDirectory标签当选择设置按钮。然后在"Appoptions"下选择"enablebuffering"。关于这个测试，Response.Buffer语句从剧本中被移走了。
之前的最好=7.05msec/page
反响工夫=5.57msec/page
差=-1.48msec(下降21.0%)
今朝，这是我们所失掉的最快反响了，比我们之前最好情形下的反响工夫还要下降21%。从如今入手下手，我们今后的测试都要把这个反响工夫作为基准值。
回忆及观察
缓冲器是进步功能的好办法，以是把缓冲器设置成服务器的默许值很有需要。假如由于某些缘故原由，页面不克不及准确地使缓冲器运转，只必要Response.Buffer=False命令便可。缓冲器的一个弱点是在全部页面处置完之前，用户从服务器看不就任何器材。因而，在庞大页面的处置时代，偶而挪用一次Response.Flush来更新用户是个好主张。
如今在我们的划定规矩中又增添了一条：老是经由过程服务器设置开启缓冲器。
是不是应当思索向ASP代码中增添正文？
年夜部分HTML开辟职员都晓得包括HTML正文不是个好主张，起首会增添传输数据的范围，其次它们只是向其余开辟职员供应有关你页面构造的信息。可是ASP页面上的正文又怎样呢？它们历来不分开服务器，但也的确要增添页面的范围，因而必需用ASP举行分化。
在此次的测试中，我们增添20条正文，每条有80个字符，统共有1600个字符。
<%OPTIONEXPLICIT
-------------------------------------------------------------------------------
…20lines…
-------------------------------------------------------------------------------
DimFirstName
…
/app2/comment_1.asp片断
基准=5.57msec/page
反响工夫=5.58msec/page
差=+0.01msec(增添0.1%)
测试的了局是惊人的。固然正文几近相称于文件自己的两倍，可是它们的存在并没有给反响工夫带来很年夜的影响。以是说我们能够遵守以下划定规矩：
只需利用过度，ASP正文对功能的影响很小或基本没有影响。
是不是应当为页面明白地设置默许言语？
IIS处置VBScript是默许的设置，可是我看到，在年夜多半例子中仍是用<%@LANGUAGE=VBSCRIPT%>声明将言语明白地设置为VBScript。我们的下一个测试将查验这个声明的存在对功能有甚么影响。
<%@LANGUAGE=VBSCRIPT%>
<%OPTIONEXPLICIT
DimFirstName
…
/app2/language1.asp片断。
基准值=5.57msec/page
反响工夫=5.64msec/page
差=+0.07msec(增添1.2%)
能够看到，包括了言语的声明对功能有一个稍微的影响。因而：
*设置服务器的默许言语设置以与站点上利用的言语相婚配。
*除非你利用非默许言语，不要设置言语声明。
假如不必要，是不是应当封闭Session形态？
制止利用IIS的Session高低文有很多来由，那些已能够自力成为一篇文章。我们如今试图回覆的成绩是当页面不必要时，封闭Session高低文是不是对功能进步有所匡助。从实际上讲应当是一定的，由于如许一来就不必要用页面例示Session高低文了。
同缓冲器一样，Session形态也有两种设置办法：经由过程剧本和经由过程服务器设置。
经由过程剧本封闭Session高低文
关于这个测试，要封闭页面中的Session高低文，我增添一个Session形态声明。
<%@ENABLESESSIONSTATE=FALSE%>
<%OPTIONEXPLICIT
DimFirstName
…
/app2/session_1.asp片断。
基准值=5.57msec/page
反响工夫=5.46msec/page
差=-0.11msec(下降2.0%)
只经由过程如许一个小小的勉力就失掉了不错的前进。如今看看第二部分。
经由过程服务器设置封闭Session高低文
要在服务器上封闭Session高低文，请到站点的Properties对话框。在HomeDirectory标签上选择Configuration按钮。然后在"Appoptions"下作废"enablesessionstate"的选择。我们在没有ENABLESESSIONSTATE声明的情形下运转测试。
基准值=5.57msec/page
反响工夫=5.14msec/page
差=-0.43msec(下降7.7%)
这是功能的又一个明显进步。以是，我们的划定规矩应是：在不必要的情形下，老是在页面或使用程序的程度上封闭Session形态。
利用OptionExplicit会使功能有本色改动吗？
在一个ASP页面的顶部设置OptionExplicit以请求一切的变量在利用之前都要在页面长进行声明。这有两个缘故原由。起首使用程序能够更快地处置变量的存取。其次，如许能够避免我们偶然中错用变量的名字。在这个测试中我们移走OptionExplicit援用和变量的Dim声明。
基准值=5.57msec/page
反响工夫=6.12msec/page
差=+0.55msec(9.8%增添)、
只管有一些代码行从页面中往失落了，反响工夫却仍然增添了。以是只管利用Optionexplicit偶然候费工夫，可是在功能上却有很明显的效果。因而我们又能够增添一条划定规矩：在VBScript中老是利用Optionexplicit。
是不是应当把剧本逻辑放在子程序和函数区？
用函数和子程序来构造和办理代码是一个很好的办法，出格是当一个代码区在页面中屡次利用的情形。弱点是要在体系上增添一个做不异事情的分外函数挪用。子程序和函数的另外一个成绩是变量的局限。从实际上说，在一个函数区内指定变量更无效。如今我们看看这两个方面怎样产生感化。
将Response.Write语句移进子程序
这个测试只是将Response.Write语句移进一个子程序区内。
…
CALLwriteTable()
SUBwriteTable()
Response.Write("<html>"&_
"<head>"&_
…
"<tr><td><b>EMail:</b></td><td>"&EMail&"</td></tr>"&_
"<tr><td><b>BirthDate:</b></td><td>"&BirthDate&"</td></tr>"&_
"</table>"&_
"</body>"&_
"</html>")
ENDSUB
/app2/function1.asp片断
基准值=5.57msec/page
反响工夫=6.02msec/page
差=+0.45msec(8.1%增添)
同意料中一样，子程序挪用给页面带来了分外的包袱。
将一切剧本移进子程序中
在这个测试中，Response.write语句与变量声明都移进一个子程序区中。
<%OPTIONEXPLICIT
CALLwriteTable()
SUBwriteTable()
DimFirstName
…
DimBirthDate
FirstName="John"
…
BirthDate="1/1/1950"
Response.Write("<html>"&_
"<head>"&_
"<title>ResponseTest</title>"&_
"</head>"&_
"<body>"&_
"<h1>ResponseTest</h1>"&_
"<table>"&_
"<tr><td><b>FirstName:</b></td><td>"&FirstName&"</td></tr>"&_
…
"<tr><td><b>BirthDate:</b></td><td>"&BirthDate&"</td></tr>"&_
"</table>"&_
"</body>"&_
"</html>")
ENDSUB
/app2/function2.asp片断
基准值=5.57msec/page
反响工夫=5.22msec/page
差=-0.35msec(6.3%下降)
十分风趣！只管将变量移到函数局限内增添了分外的函数挪用，但实践上却进步了功能。我们又能够增添以下划定规矩：
*在一个页面上，假如代码要利用一次以上，就将代码封进函数区。
*得当时分，将变量声明移到函数局限内。
利用包括文件有甚么影响？
ASP编程的一个主要功效就是包括来自别的页面的代码。经由过程这项功效，程序员能够在多个页面上共享函数，使代码更容易于保护。弱点在于服务器必需从多个来历组装页面。以下是利用Include文件的两个测试。
利用内联代码的Include文件
在这个测试中，有一小段代码被移到一个Include文件中：
<%OPTIONEXPLICIT
DimFirstName
…
DimBirthDate
FirstName="John"
…
BirthDate="1/1/1950"
%>
<!--#includefile="inc1.asp"-->
/app2/include_1.asp片断
基准值=5.57msec/page
反响工夫=5.93msec/page
差=+0.36msec(6.5%增添)
这不奇异。利用Include文件构成了负载。
在函数区利用Include文件
在这里，代码都包装在一个Include文件中的子程序里。Include援用是在页面顶部举行的，在ASP剧本的得当地位挪用子程序。
<%OPTIONEXPLICIT
DimFirstName
…
DimBirthDate
FirstName="John"
…
BirthDate="1/1/1950"
CALLwriteTable()
%>
<!--#includefile="inc2.asp"-->
/app2/include_2.asp片断
基准值=5.57msec/page
反响工夫=6.08msec/page
差=+0.51msec(9.2%增添)
这对功能酿成的影响比functions挪用还年夜。因而：只要今世码在页面之间共享时才利用Include文件。
实行毛病处置时会构成多年夜的负载？
关于一切真实的使用程序来讲，毛病处置都是需要的。这个测试中，经由过程挪用OnErrorResumeNext函数来挪用毛病句柄。
<%OPTIONEXPLICIT
OnErrorResumeNext
DimFirstName
…
/app2/error_1.asp片断
基准值=5.57msec/page
反响工夫=5.67msec/page
差=0.10msec(1.8%增添)
你能够看到，毛病句柄带来了价值。我们能够提出以下倡议：只要在会产生超越测试或把持才能以外的情形时才利用毛病句柄。一个最基础的例子就是利用存取别的资本，如ADO或FileSystem工具的COM工具。
设置一个高低文处置是不是对功能有影响？
当毛病产生时，在页面上设置一个高低文处置同意剧本举行反转操纵。这是经由过程在页面上利用处置声明来设置的。
<%@TRANSACTION=REQUIRED%>
<%OPTIONEXPLICIT
DimFirstName
…
/app2/transact1.asp片断
基准值=5.57msec/page
反响工夫=13.39msec/page
差=+7.82msec(140.4%增添)
啊！这实在最具有戏剧性的了局。以是请寄望以下划定规矩：只要当两个或更多操纵被作为一个单位实行时，才利用处置高低文。结论
本文第一部分的主要的地方在于很多大事情的积累。为了夸大这个成绩，我设置了最初一个测试，在个中举行了我们之前已经测试过的看来无所谓但实践上有坏影响的一切操纵。我包括了很多Response.Write声明、封闭了缓冲器、设置了默许言语、往失落了OptionExplicit援用并初始化了毛病句柄。
<%@LANGUAGE=VBSCRIPT%>
<%
OnErrorResumeNext
FirstName="John"
…
BirthDate="1/1/1950"
Response.Write("<html>")
Response.Write("<head>")
Response.Write("<title>ResponseTest</title>")
Response.Write("</head>")
Response.Write("<body>")
Response.Write("<h1>ResponseTest</h1>")
Response.Write("<table>")
Response.Write("<tr><td><b>FirstName:</b></td><td>"&_
"FirstName&"</td></tr>")
…
Response.Write("<tr><td><b>BirthDate:</b></td><td>"&_
"BirthDate&"</td></tr>")
Response.Write("</table>")
Response.Write("</body>")
Response.Write("</html>")
%>
/app2/final_1.asp片断
基准值=5.57msec/page
反响工夫=8.85msec/page
差=+3.28msec(58.9%增添)
听起来大概很分明，可是了解更主要，那就是我们安排在页面上的代码会对功能有影响。页面上的小变更偶然会年夜年夜地增添反响工夫。
划定规矩归纳综合
*制止内联ASP的过量利用。
*老是将一连Response.Write语句毗连进一个独自语句内。
*永久不要在Response.Write四周利用包装函数以附加CRLF。
*假如必需格局化HTML输入，间接在Response.Write语句内附加CRLF。
*老是经由过程服务器设置开启缓冲器。
*只需利用过度，ASP正文对功能的影响很小或基本没有影响。
*设置服务器的默许言语设置以与站点上利用的言语相婚配。
*除非你利用非默许言语，不要设置言语声明。
*在VBScript中老是利用Optionexplicit。
*在不必要的情形下，老是在页面或使用程序的程度上封闭Session形态。
*只要今世码在页面之间共享时才利用Include文件。
*在一个页面上，假如代码要利用一次以上，就将代码封进函数区。
*得当时分，将变量声明移到函数局限内。
*只要会产生超越测试或把持才能以外的情形时才利用毛病句柄。
*只要当两个或更多操纵被作为一个单位实行时，才利用高低文处置。
如今回忆一下，有很多成绩能够作为广泛性的目标：
*制止冗余--不要设置那些默许形态下已设置的属性。
*限定函数挪用的次数。
*减少代码的局限。
在本文的第二部分，我们将探究有关ADO和COM工具一些深切的成绩。
>>>>>未完待续<<<<<
我想详细了解ASP整站代码与PSP整站代码有什么优缺点，那个更好，更安全，更用容易维护，和管理。。。 ASP也是这几种脚本语言中最简单易学的开发语言。但ASP也是这几种语言中唯一的一个不能很好支持跨平台的语言。 因为ASP脚本语言非常简单，因此其代码也简单易懂，结合HTML代码，可快速地完成网站的应用程序。 学习ASP其实应该上升到如何学习程序设计这种境界，其实学习程序设计又是接受一种编程思想。比如ASP如何学习，你也许在以前的学习中碰到过。以下我仔细给你说几点: 交流是必要的，不管是生活还是学习我们都要试着去交流，通过交流我们可以学到很多我们自己本身所没有的知识，可以分享别人的经验甚至经历。 接下来就不能纸上谈兵了，最好的方法其实是实践。实践，只能算是让你掌握语言特性用的。而提倡做实际的Project也不是太好，因为你还没有熟练的能力去综合各种技术，这样只能使你自己越来越迷糊。 跟学别的语言一样，先掌握变量，流程控制语句(就是ifwhileselect)等，函数/过程，数组 用户端的浏览器不需要提供任何别的支持，这样大提高了用户与服务器之间的交互的速度。 掌握asp的特性而且一定要知道为什么。 ASP.Net和ASP的最大区别在于编程思维的转换，而不仅仅在于功能的增强。ASP使用VBS/JS这样的脚本语言混合html来编程，而那些脚本语言属于弱类型、面向结构的编程语言，而非面向对象，这就明显产生以下几个问题： 那么，ASP.Net有哪些改进呢？
页:
[1]