Buscar en Asptutor     
Demo Tienda Virtual Tutorcar
 Navegacion->Inicio | Active Server Pages  

La web de los recursos y ejemplos de asp

Versión para imprimir

 

Alojado en:


urbe-networks.com

Recomienda esta pagina a un amigo

Servicios Gratuitos

Articulos relacionados

Utilizar GetRows()

Tienda Virtual - Carrito de compra

Messenger a través de BD en ASP

Miniaplicacion de comercio electronico

Objeto Datagrid de ASP.NET en ASP

Acotación de resultados

Ventana SQL

Generador de listados con paginacion

Dando formato a los numeros (Función FormatDateTime)

Objeto Datagrid de ASP.NET en ASP

Control de introducción de caracteres en en formulario

Sugerencias Microsoft sobre ASP (I)

Redirección a un Frame

Paginacion de resultados Basica

Gestor de listas de correo (Ampliada)

Eliminar ficheros del servidor con FSO


Enlaces recomendados

   

Tutorial ASP

Sugerencias Microsoft sobre ASP (II)
Este articulo ha sido leído 63.681 veces

Sugerencias sobre ASP para la mejora del rendimiento y el estilo (II)


Len Cardinal, Consultor senior, Microsoft Consulting Services
George V. Reilly, Responsable de rendimiento de Microsoft IIS

Adaptación de un artículo (en inglés) de Nancy Cluts
Ingeniero de tecnología de desarrolladores
Microsoft Corporation

 

Contenido

Sugerencia 15: Actualizar las instrucciones de secuencia en línea y Response.Write
Sugerencia 16: Utilizar Response.IsClientConnected antes de aventurarse en viajes más largos
Sugerencia 17: Crear una instancia de los objetos utilizando la etiqueta <OBJECT>
Sugerencia 18: Utilizar declaraciones TypeLib con ADO y otros componentes
Sugerencia 19: Beneficiarse de las capacidades de validación del explorador
Sugerencia 20: Evitar la concatenación de las cadenas en los bucles
Sugerencia 21: Habilitar el almacenamiento en caché en el explorador y en servidores proxy
Sugerencia 22: Utilizar Server.Transfer en lugar de Response.Redirect siempre que sea posible
Sugerencia 23: Utilizar barras diagonales en las URL de directorios
Sugerencia 24: Evitar utilizar variables del servidor
Sugerencia 25: Actualizar a los últimos y los más importantes
Sugerencia 26: Ajustar el servidor Web
Sugerencia 27: Realizar pruebas de rendimiento
Sugerencia 28: Consultar los vínculos de recursos

Sugerencia 15: Actualizar las instrucciones de secuencia en línea y Response.Write

La sintaxis de VBScript <% = expression %> crea el valor de “expression” en la salida de ASP. Si el búfer de respuesta no se activa, cada una de estas instrucciones tiene como resultado que los datos se escriben en el explorador a través de la red en paquetes muy pequeños. Se trata de un proceso que lleva algún tiempo. La intercalación de pequeñas cantidades de secuencias y HTML hace que se produzca un cambio entre el motor de secuencia y el HTML, viéndose reducido el rendimiento. Por tanto, se recomienda utilizar la siguiente sugerencia: reemplazar las expresiones en línea demasiado amontonadas con una llamada a Response.Write. Por ejemplo, en la siguiente muestra aparece sólo una escritura en el flujo de respuesta por campo y fila y muchos cambios entre VBScript y HTML por fila:

<table>
<% For Each fld in rs.Fields %>
    <th><% = fld.Name %></th>
<%
Next 
While Not rs.EOF
%>
  <tr>
  <% For Each fld in rs.Fields %>
     <td><% = fld.Value %></td>
   <% Next 
  </tr>
   <% rs.MoveNext 
Wend %>
</table>

Este código más eficaz presenta una escritura en el flujo de respuesta por fila y se contiene en su totalidad en el bloque de VBScript:

<table>
<%
  For each fld in rs.Fields
      Response.Write ("<th>" & fld.Name & "</th>" & vbCrLf)
  Next
  While Not rs.EOF
    Response.Write ("<tr>")
    For Each fld in rs.Fields %>
      Response.Write("<td>" & fld.Value & "</td>" & vbCrLf)
    Next
    Response.Write "</tr>"
  Wend
%>
</table>

El efecto que se obtiene al seguir esta sugerencia es mucho mayor cuando se encuentra deshabilitada la opción de búfer de respuesta. Habilite el búfer de respuesta y compruebe que la actualización de Response.Write incide positivamente en el rendimiento.

(En este ejemplo concreto, el bucle anidado que consituye el cuerpo de la tabla (While Not rs.EOF...) puede reemplazarse por una llamada cuidadosamente elaborada a GetString (en inglés)).

Sugerencia 16: Utilizar Response.IsClientConnected antes de aventurarse en viajes más largos

Si un usuario se impaciencia ante la tardanza de la descarga de una página ASP, puede abandonarla incluso antes de que se empiece a ejecutar su solicitud. Si hace clic en el botón Actualizar o cambia a otra página en el servidor, se dispondrá una nueva solicitud al final de la cola de solicitudes ASP y una solicitud desconectada en mitad de la misma. Esto ocurre con relativa frecuencia cuando el servidor debe soportar una carga elevada (cuando tiene una cola extensa de solicitudes a las que debe responder con tiempos de respuesta también bastante largos), con lo que lo único que se consigue es empeorar la situación. No tiene sentido ejecutar una página ASP (especialmente una lenta y con mucha carga) si el usuario ya no se encuentra conectado. Esta circunstancia se puede comprobar con la propiedad Response.IsClientConnected. Si devuelve False, se debería llamar a Response.End y abandonar el resto de la página. De hecho, IIS 5.0 codifica esta operación: siempre que una página ASP está a punto de ejecutar una solicitud, ésta se comprueba para ver cuanto tiempo ha permanecido en la cola. Si ha superado los 3 segundos, ASP comprobará que el cliente aún sigue conectado y, si no fuera así, finalizaría la solicitud inmediatamente. Se puede utilizar AspQueueConnectionTestTime en la metabase para ajustar el tiempo de espera a 3 segundos.

Si la página tarda demasiado en ejecutarse, se puede comprobar Response.IsClientConnected a intervalos. Cuando se habilita el búfer de respuesta, resulta una buena idea ejecutar Response.Flush a intervalos para dar al usuario la impresión de que está sucediendo algo.

Nota: en IIS 4.0, Response.IsClientConnected no funcionará correctamente a menos que se utilice primero Response.Write. Si se habilita el almacenamiento en búfer, también se deberá utilizar Response.Flush. En IIS 5.0, no es preciso emplearlo: Response.IsClientConnected funciona correctamente. En cualquier caso, Response.IsClientConnected supone ciertos costes, por lo que sólo se debe utilizar antes de operaciones en las que se inviertan, al menos, 500 milisegundos (un intervalo largo si lo que se intenta es mantener una salida de docenas de páginas por segundo). Como norma, es mejor no llamarlo en cada iteración de un bucle estrecho, como cuando se crean las filas de una tabla; quizás sería mejor realizarlo cada 20 o 50 filas de la tabla.

Sugerencia 17: Crear una instancia de los objetos utilizando la etiqueta <OBJECT>

Si precisa hacer referencia a los objetos que puede que no se utilicen en todas las rutas del código (especialmente en los objetos del ámbito de servidor o de aplicación), puede declararlos utilizando la etiqueta <object runat=server id=objname> en Global.asa en lugar del método Server.CreateObject. Dicho método Server.CreateObject crea el objeto inmediatamente. Si más tarde no vuelve a utilizarlo, acabará malgastando los recursos. La etiqueta <object id=objname> declara objname, pero en realidad objname no se crea hasta que se utilizan por primera vez uno de sus métodos o propiedades.

Se trata de otro ejemplo de evaluación perezosa.

Sugerencia 18: Utilizar declaraciones TypeLib con ADO y otros componentes

Cuando utilizan ADO, los desarrolladores incluyen con frecuencia adovbs.txt para obtener acceso a las distintas constantes de ADO. Este archivo debe incluirse en cada página en la que se desea que se haga uso de dichas constantes y su tamaño es relativamente extenso, con lo que se agrega una carga considerable al tamaño de secuencia y al tiempo que se invierte en la compilación de cada página ASP.

IIS 5.0 incorpora una nueva capacidad para enlazar a una biblioteca de tipos que permite hacer una referencia a la misma una vez y utilizarla en cada página ASP. Con ello las páginas no se ven obligadas a compilar el archivo de constantes y los desarrolladores de componentes eliminan la necesidad de crear archivos #include de VBScript para su utilización en ASP.

Para obtener acceso a TypeLib de ADO, introduzca una de las siguientes instrucciones en Global.asa.

<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library"
              TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->

o bien,

<!-- METADATA TYPE="TypeLib" 
              FILE="C:\Archivos de programa\Archivos comunes\system\ado\msado15.dll" -->

Sugerencia 19: Beneficiarse de las capacidades de validación del explorador

Los exploradores más actuales admiten características avanzadas como XML, DHTML, miniaplicaciones Java y Remote Data Service (todos en inglés). Puede beneficiarse de estas características siempre que sea posible, ya que lo que todas estas tecnologías comparten es su capacidad para evitar los rodeos a la hora de tener acceso al servidor Web gracias a la validación del lado del cliente y al almacenamiento en caché de los datos. Si ejecuta un explorador inteligente, éste podrá realizar la validación (por ejemplo, comprobando que una tarjeta de crédito dispone de una suma de comprobación válida (en inglés) antes de ejecutar el comando). De nuevo, aprovéchese de esta característica siempre que sea posible. Al recortar los rodeos entre el cliente y el servidor, se reducirá la carga del servidor Web y el tráfico de la red (aunque es probable que la primera página que se envíe al explorador sea más extensa), así como en los recursos centrales a los que tiene acceso el servidor. Por otra parte, el usuario no tendrá que visitar nuevas páginas de forma tan frecuente, mejorándose así su experiencia en el Web. No obstante, esto no libera al desarrollador de la carga de tener que realizar la validación en el lado del servidor, de igual manera era necesario llevarla a cabo, ya que de este modo se evitan circunstancias como datos incorrectos o exploradores que no ejecutan rutinas de validación en el lado del cliente.

Debido al hincapié que se ha hecho en la creación de HTML “independiente del explorador”, esta cuestión a menudo ha servido para animar al desarrollador a no utilizar las características más comunes del explorador que pudieran incidir positivamente en el rendimiento. En aquellos sitios en los que el alto rendimiento depende en gran medida del “alcance” del explorador, una buena estrategia es optimizar las páginas para los exploradores más utilizados, con lo que ASP podría detectar fácilmente sus características con el componente de capacidades del explorador. Herramientas como Microsoft FrontPage pueden ayudarle a diseñar un código que funcione con los exploradores y con las versiones de HTML que tiene como objetivo. Consulte When is Better Worse? Weighing the Technology Trade-Offs (en inglés) para obtener información adicional.

Sugerencia 20: Evitar la concatenación de las cadenas en los bucles

Muchos desarrolladores construyen cadenas en un bucle como sigue:

s = "<table>" & vbCrLf
For Each fld in rs.Fields
    s = s & " <th>" & fld.Name & "</th> "
Next

While Not rs.EOF
    s = s & vbCrLf & " <tr>"
    For Each fld in rs.Fields
        s = s & " <td>" & fld.Value & "</td> "
    Next
    s = s & " </tr>"
    rs.MoveNext
Wend

s = s & vbCrLf & "</table>" & vbCrLf
Response.Write s

Sin embargo, este enfoque presenta algunos problemas. El primero es que el tiempo invertido en la concatenación repetida de cadenas es cuadrático; por decirlo de forma menos formal, el tiempo que se invierte en ejecutar el bucle es proporcional al cuadrado del número de registros multiplicado por el número de campos. Un ejemplo más simple aclararía las cosas.

s = ""
For i = Asc("A") to Asc("Z")
    s = s & Chr(i)
Next

En la primera iteración se obtiene una cadena de un único carácter, "A". En la segunda, VBScript debe asignar la cadena y copiar dos caracteres ("AB") a s. En la tercera debe volver a asignar s y copiar tres caracteres a s. En la iteración Nª (26ª), debe reasignar y copiar N caracteres a s. Esto resulta en un total de 1+2+3+...+N que son N*(N+1)/2 copias.

En el ejemplo de recordset anterior, si hubiera 100 registros y 5 campos, el bucle más interno se ejecutaría 100*5 = 500 veces y el tiempo invertido en todo el proceso de copia y reasignación sería proporcional a 500*500 = 250.000, valor algo elevado para un modesto recordset.

En este ejemplo, el código podría mejorarse reemplazando la concatenación de la cadena con Response.Write() o la secuencia en línea (<% = fld.Value %>). Si se activa el búfer de respuesta (recomendado), el proceso sería más rápido, ya que Response.Write se agregaría a los datos al final de cada búfer de respuesta. No sería necesario llevar a cabo ninguna reasignación adicional y resultaría un método muy eficaz.

En el caso concreto de la transformación de un recordset ADO en una tabla HTML, considere la posibilidad de utilizar GetRows o GetString (en inglés).

Si se concatenan las cadenas en JScript, se recomienda que se emplee el operador +=; es decir, utilizar s += "cadena", no s = s + "cadena".

Sugerencia 21: Habilitar el almacenamiento en caché en el explorador y en servidores proxy

De forma predeterminada, ASP deshabilita el almacenamiento en caché en exploradores y servidores proxy, algo que tiene sentido ya que, por naturaleza, una página ASP es dinámica y contiene información que se modifica con el tiempo. Si, por el contrario, la página no requiere actualización cada vez que se visita, se debería habilitar el almacenamiento en caché en el explorador y el servidor proxy. De esta forma podrían utilizar una copia “almacenada en caché” de una página durante un período de tiempo concreto que se puede controlar con facilidad. El almacenamiento en caché puede aliviar en gran medida la carga que debe soportar el servidor y mejorar así la experiencia del usuario que tiene acceso a la página.

¿Qué tipo de páginas dinámicas pueden ser candidatas para el almacenamiento en caché? Aquí se ofrecen algunos ejemplos:

  • Una página dedicada a la meteorología, en la que el pronóstico del tiempo se actualiza sólo cada 5 minutos.
  • Una página principal en la que se proporcionan noticias o comunicados de prensa y que se actualiza dos veces al día.
  • Una página de un fondo de inversión mobiliaria en la que las estadísticas se actualizan cada pocas horas.

Tenga en cuenta que con el almacenamiento en el explorador y el servidor proxy se obtendrán menos registros en el servidor Web. Si lo que desea es contar con un análisis detallado y preciso de todas las vistas de las páginas, por ejemplo, puede que el almacenamiento de este tipo no proporcione los resultados deseados.

El almacenamiento en el explorador se controla por medio del encabezado HTTP “Expires”, que el servidor Web envía al explorador. ASP proporciona dos simples mecanismos que permiten enviar este encabezado. Para que una página caduque tras un número específico de minutos en el futuro, establezca la propiedad Response.Expires. El ejemplo siguiente indica al explorador que el contenido caducará a los 10 minutos:

<% Response.Expires = 10 %> 

Establecer Response.Expires en un valor negativo o en 0 deshabilitará el almacenamiento en caché. Asegúrese de que utiliza números negativos altos, como -1.000 (un poco más de un día), para solucionar las discrepancias entre los relojes del servidor y los exploradores. Una segunda propiedad, Response.ExpiresAbsolute, permite establecer el intervalo de tiempo después del cual caducará el contenido:

<% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %>

En lugar de utilizar el objeto Response para establecer el momento en el que caducará la página, se puede escribir una etiqueta <META> en el código HTML, generalmente incluida en la sección <HEAD> del archivo HTML. Algunos exploradores respetarán esta directriz, pero no los servidores proxy.

<META HTTP-EQUIV="Expires" VALUE="May 31,2001 13:30:15">

Por último, se puede indicar si el contenido es válido para que lo almacene en caché un servidor proxy, utilizando la propiedad Response.CacheControl. Si se establece como “Public”, se habilitarán los servidores proxy, que almacenarán en caché dicho contenido.

<% Response.CacheControl = "Public" %>

De forma predeterminada, esta propiedad se establece como “Private”. Tenga en cuenta que no se debe habilitar el almacenamiento en caché en el servidor proxy en el caso de las páginas que muestran datos específicos de un usuario, ya que el servidor proxy podría proporcionar dichas páginas a otros.

Sugerencia 22: Utilizar Server.Transfer en lugar de Response.Redirect siempre que sea posible

Response.Redirect indica al explorador que debe solicitar otra página. Esta función se utiliza a menudo para redireccionar al usuario a una página de registro o de error. Debido a que el redireccionamiento fuerza una nueva solicitud de página, el resultado es que el explorador debe visitar dos veces el servidor Web y que éste debe administrar una solicitud adicional. IIS 5.0 introduce una nueva función, Server.Transfer, que transfiere la ejecución a otra página ASP en el mismo servidor. De esta forma se evita que el explorador busque una segunda vez en el servidor Web, con el resultado de una mejora en el rendimiento general del sistema, así como un mejor tiempo de respuesta para el usuario. Consulte New Directions in Redirection (en inglés), donde podrá encontrar detalles sobre Server.Transfer y Server.Execute.

Asimismo recomendamos que consulte Leveraging ASP in IIS 5.0 (en inglés) para obtener la lista completa de nuevas características de IIS 5.0 y ASP 3.0.

Sugerencia 23: Utilizar barras diagonales en las URL de directorios

Una sugerencia relacionada es la utilización de una barra diagonal al final (/) de las URL que conduzcan a los directorios. Si se omite dicha barra, el explorador realiza una solicitud al servidor, sólo para que se le informe de que está solicitando un directorio. El explorador entonces intenta una segunda solicitud con la barra agregada a la URL y sólo entonces responde el servidor con el documento predeterminado del directorio, o bien, con una lista de directorios, si es que no existiera documento predeterminado y se encontrara habilitada la exploración del mismo. Agregar la barra supone ir directamente al segundo paso. No obstante, para una mayor comodidad del usuario puede que sea interesante omitir la barra en los nombres de pantalla.

Por ejemplo, introduzca:

<a href="http://msdn.microsoft.com/workshop/" title="MSDN Web
Workshop">http://msdn.microsoft.com/workshop</a>

Esto también se aplica a las URL que conducen a la página principal en un sitio Web: utilice lo siguiente: <a href="http://msdn.microsoft.com/">, no <a href="http://msdn.microsoft.com">.

 

Sugerencia 24: Evitar utilizar variables del servidor

Tener acceso a las variables del servidor supone que el sitio Web debe realizar una solicitud especial al servidor y recopilar todas sus variables, no exclusivamente la solicitada. Esto es casi lo mismo que intentar recuperar algo de una carpeta que se encuentra en un mohoso desván; es necesario subir al desván y obtener primero la carpeta antes de poder conseguir el elemento. Algo muy similar ocurre cuando se solicita una variable del servidor: el rendimiento se ve ligeramente afectado por la primera solicitud de variable que se hace al servidor. Las solicitudes posteriores de variables adicionales no afectan al rendimiento.

Nunca se debe tener acceso a un objeto Request no calificado (por ejemplo, Request(“Data”)). En el caso de los elementos que no se encuentran en Request.Cookies, Request.Form, Request.QueryString o Request.ClientCertificate, existe una llamada implícita a Request.ServerVariables. La colección Request.ServerVariables es mucho más lenta que las demás.

Sugerencia 25: Actualizar a los últimos y los más importantes

Los componentes experimentan actualizaciones constantes y, por nuestra parte, recomendamos que el sistema se actualice con los últimos y más importantes componentes del mercado. La mejor opción es actualizar a Windows 2000 (en inglés) (y por consiguiente, a IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 y JScript 5.1). IIS 5.0 y ADO 2.5 permiten implementar unas espectaculares mejoras en el rendimiento en equipos con varios procesadores. Con Windows 2000, ASP se puede escalar con cuatro o más procesadores, mientras que con IIS 4.0, ASP no se escalaba bien con sólo dos procesadores. Cuanto mayor sea el uso que se haga del código de secuencias y de ADO en la aplicación, mayores serán las ventajas en cuanto a rendimiento una vez se realice la actualización a Windows 2000.

Si aún no puede actualizar el sistema a Windows 2000, sí que podrá hacerlo con las últimas versiones de SQL Server, ADO, VBScript y JScript, MSXML, Internet Explorer (todos en inglés) y NT 4 Service Packs. Todos ellos ofrecen un rendimiento mejorado así como una mayor confiabilidad.

Sugerencia 26: Ajustar el servidor Web

Varios son los parámetros de ajuste de IIS que permiten mejorar el rendimiento de un sitio. Por ejemplo, en IIS 4.0, a menudo hemos comprobado que incrementar el parámetro ASP ProcessorThreadMax (consulte la documentación de IIS) puede suponer ventajas significativas, especialmente en aquellos sitios que tienden a esperar recursos centrales como bases de datos u otros productos de software intermedio como son los denominados “rascapantallas”. En IIS 5.0, puede que encuentre que activar ASP Thread Gating resulta mucho más eficaz que intentar buscar una configuración opcional para AspProcessorThreadMax, como es bien sabido.

Para obtener una referencias de gran utilidad, consulte Ajuste de IIS.

Las opciones de configuración óptimas las determinan (entre otros factores) el código de la aplicación, el hardware que se ejecuta en la misma y la carga del cliente. La única manera de descubrir cuál es la configuración más adecuada es ejecutar pruebas de rendimiento, lo que nos lleva a la siguiente sugerencia.

Sugerencia 27: Realizar pruebas de rendimiento

Como se señaló anteriormente, el rendimiento es una característica esencial. Si la intención es mejorar el rendimiento de un sitio, es necesario establecer el objetivo deseado y, a continuación, introducir mejoras progresivas hasta lograr dicho objetivo. No resulta recomendable dejar todas las pruebas de rendimiento para el final del proyecto, ya que sería demasiado tarde para realizar cambios en la arquitectura y el cliente no estaría satisfecho en absoluto. Nuestra recomendación es que las pruebas se realicen como parte de la rutina de comprobación diaria; se pueden llevar a cabo pruebas de componentes por separado, como objetos COM o páginas ASP, o bien del sitio en su totalidad.

Muchos realizan las pruebas de rendimiento de sus sitios Web utilizando un único explorador que iría solicitando las páginas; no obstante, aunque esto puede dar un resultados muy positivos en cuanto a la respuesta del sitio a las solicitudes, no proporciona información alguna sobre su rendimiento en situaciones de exceso de carga.

Por regla general, para valorar de forma precisa el rendimiento de un sitio es necesario contar con un entorno de comprobación dedicado que incluya un hardware que se asemeje a un hardware de producción en cuanto a velocidad del procesador, número de procesadores, memoria, disco, configuración de red, etc. El siguiente paso consiste en establecer la carga de trabajo del cliente: el número de usuarios simultáneos, la frecuencia de las solicitudes, los tipos de páginas que se visitan, etc. Si no se tiene acceso a los datos de uso reales, se debe realizar un cálculo aproximado. Por último, se debe contar con una herramienta que pueda simular las cargas de trabajo de los clientes con anticipación. Con todas estas armas se puede empezar a formular preguntas como “¿Cuántos servidores necesitaré si cuento con N usuarios simultáneos?” Podrá descubrir los cuellos de botella y optimizar la situación.

En la sesión siguiente se enumeran una serie de útiles herramientas para realizar pruebas de carga en el Web. Recomendamos sin reservas la herramienta de carga para aplicaciones Web (WAS). WAS permite registrar secuencias de pruebas y simular cientos o miles de usuarios teniendo acceso a los servidores Web. WAS proporciona numerosos informes de estadísticas, incluyendo las solicitudes por segundo, las distribuciones de los tiempos de respuesta y los recuentos de errores. Se trata de una aplicación con una interfaz rica basada en el Web que además permite ejecutar las pruebas de forma remota.

No olvide consultar IIS 5.0 Tuning Guide (en inglés).

Sugerencia 28: Consultar los vínculos de recursos

A continuación se enumeran algunos interesantes vínculos a recursos relacionados con el rendimiento. Si hay alguno de consulta obligada, ese es Developing Scalable Web Applications (en inglés).

Recursos

Optimización de secuencias ASP Ajuste de IIS ADO y SQL Server
Componentes ASP y modelos de subprocesamiento Componentes de diccionario Estado de la sesión
Rendimiento y escalabilidad Herramientas Literatura
Sitios Web de ASP Estilo ASP XML

Optimización de secuencias ASP

Ajuste de IIS

ADO y SQL Server

Componentes ASP y modelos de subprocesamiento

Componentes de diccionario

Estado de la sesión

Rendimiento y escalabilidad

Herramientas

Literatura

Sitios Web de ASP

Estilo ASP

XML

 



 

¿Estas empezando y este articulo es muy complejo para tí?
Empieza por el principio, visita Ejemplos Básicos

Puedes obtener un listado completo de todos los artículos y ejemplos de ASP en http://www.asptutor.com/asp/todoslosarticulos.asp
 

Valora este articulo   Malo Excelente  
26 usuarios han valorado este articulo. Valoracion media:

Nota: Para cualquier consulta u opinión sobre este articulo puedes usar los foros

 

 

AspTutor lo hacemos entre todos ¿Como vas a colaborar hoy?


Google

 

Descargas de manuales¦ Ejemplos de código ¦ Artículos mas visitados ¦ Envía tu articulo ¦ Foros ¦
  Libro de visitas ¦Crea un enlace con ASPTutor 
 

    © 2001-Hasta hoy  Pedro Rufo Martín  contactar