ASP classic中的许多包含("case")是否损害了服务器的性能？

Question

我想用ASP classic:构建这个页面

<%
Dim depart
depart = 1556

Select Case depart
    Case 1
    %>
    <!--#include virtual="/check/noam/newDesign/test1.asp"-->
    <%
    Case 2
    %>
    <!--#include virtual="/check/noam/newDesign/test2.asp"-->
    <%
    Case 3
    %>
    <!--#include virtual="/check/noam/newDesign/test3.asp"-->
    <%
    Case 4
    %>
    <!--#include virtual="/check/noam/newDesign/test4.asp"-->
    <%
    Case 5
    %>
    <!--#include virtual="/check/noam/newDesign/test5.asp"-->
    <%
    Case 6
    %>
    <!--#include virtual="/check/noam/newDesign/test6.asp"-->
    <%
    Case 7
    %>
    <!--#include virtual="/check/noam/newDesign/test7.asp"-->
    <%
    Case 8
    %>
    <!--#include virtual="/check/noam/newDesign/test8.asp"-->
    <%
End If
%>

我想知道后台的服务器是否需要输入每个include，或者在正确的情况下他只输入include？我需要知道这一点，因为我想知道这个服务器是否会有糟糕的性能。

Answer 1

这实际上取决于include内部的内容，但我不认为这样的结构会对性能产生任何可观察到的影响，除非您每秒有100秒的case语句或100秒的页面请求。

的确，在执行代码之前，所有的include都会首先被合成到脚本中，但也应该记住，最终脚本的合成和解析的"p代码"版本是由ASP缓存的。

如果includes主要只是静态HTML内容，那么这种方法实际上是非常有效的。另一方面，内联全局标识符（未包含在Sub、Function或Class中的标识符）越多，在脚本上下文中注册这些标识符所需的时间就越多（然而，仍需要批来产生显著差异）。

一个潜在的替代方案是使用Server.Execute而不是include。在这种情况下，执行的ASP有自己的独立脚本上下文，因此它不能共享调用方函数和变量（这可能是好事，也可能不是好事。）此外，Server.Execute实际上可能会变慢。

Answer 2

Includes是在经典ASP中执行之前加载的，所以基本上就是加载所有这些include，即使它们没有执行。

您可以使用不同的模式：Execute Global，这相当于在VB中使用eval（）。您将文件作为字符串读取，然后执行它。这绕过了include集群，但其本身相当丑陋。

Answer 3

您可以使用server.execute

server.execute("/check/noam/newDesign/test"&depart&".asp")

或

page="/check/noam/newDesign/test"&depart&".asp"
server.execute(page)