ASP (Dicas de performance)


Resumo das regras

Geralmente criamos uma "wrapper function" para o Response.Write colocar um CRLF em cada linha.
…
writeCR("<tr><td><b>First Name:</b></td><td>" & FirstName & "</td></tr>")
…
SUB writeCR(str)
    Response.Write(str & vbCRLF)
END SUB
No caso acima, perde performance.
O código abaixo é melhor.
…
Response.Write("<html>" & _
     "<head>" & _
     "<title>Response Test</title>" & _
     "</head>" & _
     "<body>" & _
     "<h1>Response Test</h1>" & _
     "<table>" & _
     "<tr><td><b>First Name:</b></td><td>" & FirstName & "</td></tr>" & _
…
     "<tr><td><b>Birth Date:</b></td><td>" & BirthDate & "</td></tr>" & _
     "</table>" & _
     "</body>" & _
     "</html>")


Sempre use o 'Option Explicit'.



Não use Server.MapPath a menos que vc realmente precise. Ao invés disso digite o path se vc souber. Usar MapPath faz o IIS buscar o caminho atual do servidor, o que significa uma requisição especial para o IIS, piorando a performance. Outro jeito é armazenar o caminho numa variável local e usá-la qdo necessário.



Se vc precisa se referir a objetos que podem não serem realmente usados, instancie-os utilizando <OBJECT> tab ao invés de Server.CreateObject. Usando Server.CreateObject obriga o objeto a ser criado imediatamente, enquanto isso não ocorre com a tag <OBJECT>. Se vc não usar o objeto mais tarde, vc não gastará recurso com <OBJECT>.
Por exemplo, instanciando o objeto Ad Rotator com a tag <OBJECT>:
<OBJECT runat=server scope=Application id=MyAds progid="MSWC.AdRotator">
</OBJECT>
Depois de armazenar o objeto Ad Rotator no estado de Application, vc pode acessar de qualquer página da sua aplicação usando um código como o seguinte:
<%=MyAds.GetAdvertisement("CustomerAds.txt") %>


Se está usando SQL Server 7, use essa string de conecção:
strConnString = "DSN='';DRIVER={SQL SERVER};" & _ 
                "UID=myuid;PWD=mypwd;" & _ 
                "DATABASE=MyDb;SERVER=MyServer;" 
O parâmetro mais importante é o DRIVER. Se vc quer evitar a camada do ODBC e usar o SQL Server pelo OLE DB (esse deveria ser o mais rápido), use essa sintaxe:
strConnString ="Provider=SQLOLEDB.1;Password=mypassword;" & _ 
               "Persist Security Info=True;User ID=myuid;" & _ 
               "Initial Catalog=mydbname;" & _ 
               "Data Source=myserver;Connect Timeout=15" 
Hoje, já dizem que o ADO supera em performance.



Se vc não está usando variáveis de sessão, que realmente vc provavelmente não precisa (Utilizando campos hidden de form, armazenando valores em banco de dados, e usando query strings, podem fazer o trabalho), então para desabilitar o Session State declare:
@EnableSessionState = False
O ASP não irá mais procurar por informação de sessão.



Todos fazem isso, nós trocamos entre código ASP e HTML quando mostramos tabelas, o que não é uma boa prática.
<HTML>
<BODY>
<%
  Set MyConn = Server.CreateObject("ADODB.Connection")
  MdbFilePath = Server.MapPath("sample.mdb")
  MyConn.Open "Driver={Microsoft Access Driver (*.mdb)}; DBQ=" & MdbFilePath & ";"
  SQL_query = "SELECT * FROM Friends"
  Set RS = MyConn.Execute(SQL_query)
  WHILE NOT RS.EOF
%>
<LI><%=RS("Name")%>: <A HREF="<%=RS("Link")%>">Homepage</A>
<%
  RS.MoveNext
  WEND
%>
</BODY>
</HTML>
Nesses casos, a performance pode ser melhorada mantendo blocos de ASP server-side script juntos, e usando Response.Write para gerar nosso código HTML, como:
<%
If not Session ("DBOpen") Then
   Response.Write "<H1>Database not connected</H1>"
Else
   Response.Write "<H1>Database open</H1>"
End If
%>


Certifique-se de usar Response.IsClientConnected se seu script for grande. Isso significa que sua CPU pode evitar ciclos desperdiçados se o usuário não estiver mais conectado.
<% 
'verifica se usuário está conectado
If Not Response.IsClientConnected Then 
  'ainda conectado, portanto continue
Else 
  'desconectado 
End If
%>




Indice
1