Rendimiento de .NET Remoting, Enterprise Services y servicios Web ASP.NET
TOC
Collapse the table of content
Expand the table of content

Rendimiento de .NET Remoting, Enterprise Services y servicios Web ASP.NET

Agosto de 2005

Publicado: 19 de Octubre de 2005

Ingo Rammer
thinktecture

Richard Turner
Program Manager
Microsoft Distributed Systems Group

Nota

Compare y contraste las características de rendimiento de los componentes de .NET Remoting, los componentes de .NET Enterprise Services y los servicios Web ASP.NET en el mundo real. También encontrará recomendaciones sobre cuáles son los mejores usos de estas tecnologías. (34 páginas impresas.) (Este artículo contiene vínculos a páginas en inglés.)

Descargar el ejemplo de código asociado, ASMXvsEnterpriseServicesvsRemotingPerformanceTests.msi..

En esta página

Introducción Introducción
Objetivos Objetivos
Esto no es una prueba comparativa Esto no es una prueba comparativa
Las pruebas Las pruebas
Los resultados Los resultados
Prueba 1: Creación y almacenamiento de pedidos Prueba 1: Creación y almacenamiento de pedidos
Prueba 2: Recuperación de datos de productos de Northwind Prueba 2: Recuperación de datos de productos de Northwind
Prueba 3: Recuperación de información sobre clientes Prueba 3: Recuperación de información sobre clientes
Rendimiento de .NET Framework 2.0 Rendimiento de .NET Framework 2.0
Conclusiones Conclusiones
Recomendaciones Recomendaciones
Apéndice A: Línea de base sintética, prueba del método vacío Apéndice A: Línea de base sintética, prueba del método vacío
Apéndice B: Resultados detallados de las pruebas Apéndice B: Resultados detallados de las pruebas
Almacenamiento de pedido como DataSet Almacenamiento de pedido como DataSet
Carga de productos como objetos Carga de productos como objetos
Carga de productos como DataSet Carga de productos como DataSet
Carga de cliente como objeto Carga de cliente como objeto
Carga de cliente como DataSet Carga de cliente como DataSet
Mensaje vacío, a través de procesos Mensaje vacío, a través de procesos
Mensaje vacío, a través de equipos Mensaje vacío, a través de equipos
Apéndice C: Notas sobre la aplicación de prueba Apéndice C: Notas sobre la aplicación de prueba
Ejecución de la aplicación de prueba Ejecución de la aplicación de prueba
Idea interesante: la aplicación de prueba es agnóstica respecto a la tecnología Idea interesante: la aplicación de prueba es agnóstica respecto a la tecnología
Apéndice D: Configuración de software y hardware Apéndice D: Configuración de software y hardware
Entorno de la aplicación Entorno de la aplicación
Entorno de la infraestructura Entorno de la infraestructura

Introducción

Mientras que el rendimiento absoluto es la máxima preocupación para varias áreas de la tecnología (dispositivos, controladores de hardware, servicios sanitarios y médicos, determinados sistemas financieros), éstas tienden a ser una minoría. Los principales objetivos de la mayoría de las aplicaciones empresariales son la "exactitud", el "tiempo de entrega" y la necesidad de ser tan rápidas como sea necesario, pero no más. El coste y el esfuerzo que supone diseñar aplicaciones que ofrezcan el rendimiento máximo absoluto posible pueden ser enormes; la cantidad considerable de tiempo y conocimientos necesaria para obtener el máximo rendimiento no suele ser necesaria para muchos sistemas empresariales. Sin embargo, aunque a menudo se exagera el máximo rendimiento absoluto, garantizar un buen rendimiento global del sistema sigue siendo un objetivo para la mayoría de las empresas que desean maximizar los beneficios obtenidos con la inversión.

En este artículo, veremos un análisis comparativo de los niveles de rendimiento relativo de los servicios y componentes reales que alojan cada una de las tres tecnologías de servicios y componentes distribuidos que ofrece .NET:

  • .NET Enterprise Services (ES) alojados en COM+

  • Servicios Web ASP.NET (ASMX) alojados en IIS

  • .NET Remoting alojado en IIS y hosts personalizados

Nota: El rendimiento de System.Messaging respecto a las API MSMQ COM se tratará en el artículo System.Messaging Performance

Objetivos

Existe un debate interminable acerca de "cuál es la tecnología de aplicación distribuida más rápida de Microsoft" o afirmaciones de que "inserte aquí el nombre de la tecnología" es demasiado lento para que podamos utilizarla". El objetivo principal de este artículo es detallar y aclarar muchas de las preocupaciones, creencias erróneas, inexactitudes e información incorrecta acerca del rendimiento de las tecnologías distribuidas de Microsoft.

Nos gustaría erradicar muchas creencias erróneas acerca de las características de rendimiento relativo de cada una de las tecnologías de componentes y servicios distribuidos de Microsoft, así como ofrecer un conjunto claro de pruebas ilustrativas y sus resultados, junto con un conjunto de orientación que le ayude a elegir la tecnología más adecuada para sus necesidades.

Como resumen, los objetivos de este artículo son:

  1. Investigar qué diferencias de rendimiento relativo existen entre las tres tecnologías para la mayoría de las aplicaciones empresariales.

  2. Corregir algunas ideas acerca de las penalizaciones de rendimiento que se cree que unas tecnologías tienen sobre otras.

  3. Ayudar a tomar decisiones acerca de dónde, cuándo y cómo utilizar cada tecnología de la manera más adecuada.

  4. Ofrecer una aplicación de prueba para que pueda ejecutar estas pruebas en sus propios entornos y equipos. Le recomendamos que genere y ejecute este entorno de prueba para investigar y analizar las características de rendimiento de estas tecnologías, lo que permitirá comprender completamente los numerosos factores que afectan al rendimiento de los sistemas distribuidos.

Esto no es una prueba comparativa

Las pruebas que se presentan en este artículo se han diseñado explícitamente para ofrecer resultados comparativos coherentes entre las tecnologías concretas que se han probado. Estas pruebas no se han diseñado para medir el rendimiento absoluto máximo posible de cada tecnología bajo carga.

La aplicación de controlador de prueba (cliente) tiene un único subproceso, por lo que las llamadas síncronas serie se realizan tan rápidamente como responde el servicio al que se llama. Con este diseño, el cuello de botella no es siempre el uso de CPU del servidor.

Si se utilizan varios clientes o un cliente con varios subprocesos, es posible que el servidor procese más llamadas por segundo. Para pruebas de aplicación de servidor que realicen un uso tan intenso de la CPU, varios clientes no cambiarán significativamente el rendimiento absoluto o relativo de las tecnologías que se están probando.

Para las pruebas más ligeras, se puede alcanzar una productividad del servidor agregado considerablemente superior (2X) si se utilizan varios clientes. Si se utilizan varios clientes también puede cambiar un tanto el rendimiento relativo de las diferentes tecnologías.

Si es más realista un único cliente o varios clientes depende de dónde y cómo se implementa un servicio Web. Las conclusiones de este artículo no se ven afectadas por la decisión de tomar las medidas con un único cliente.

Las pruebas

En las siguientes pruebas de rendimiento, exploramos tanto líneas de base sintéticas como escenarios del mundo real. Las preguntas más habituales que nos disponemos a responder son:

  1. ¿Es .NET Remoting más rápido que ASMX?

  2. ¿Es ES más lento que Remoting?

  3. ¿Es ASMX demasiado lento para escenarios reales?

  • Para examinar estas afirmaciones, hemos realizado varias pruebas. Las pruebas principales examinan el rendimiento obtenido al realizar llamadas respecto a acciones que aceptan una solicitud grande y realizan bastantes tareas o que se solicita que realicen bastantes tareas y devuelvan conjuntos de resultados pequeños o grandes. El objetivo de estas pruebas es ilustrar el rendimiento de varios escenarios empresariales habituales con los que es probable que se encuentre al crear sistemas.

Todas estas pruebas se ejecutaron respecto a cada uno de los protocolos de las tecnologías disponibles:

  • Enterprise Services (utilizando activación instantánea)

    • Sin autenticación

    • Autenticación de nivel de llamadas y comprobaciones de acceso a funciones obligatoria

  • Servicios Web ASP.NET

    • Sin autenticación

    • Autenticación mediante nombre de usuario y contraseña

    • Autenticación integrada

  • .NET Remoting

    • TCP/binario, sin protección

    • HTTP/binario, sin protección

    • HTTP/SOAP, sin protección

    • HTTP/SOAP en IIS, sin protección

    • HTTP/binario en IIS, sin protección

    • HTTP/SOAP en IIS, autenticación básica HTTP

    • HTTP/binario en IIS, autenticación básica HTTP

    • HTTP/SOAP en IIS, autenticación integrada

    • HTTP/binario en IIS, autenticación integrada

Todas las siguientes pruebas se basan en una aplicación de un solo cliente que llama repetidamente a métodos del servidor. Hemos calculado el número medio de llamadas remotas por segundo de cada prueba del conjunto y hemos repetido el conjunto completo 10 veces para determinar la media y la desviación estándar para una ejecución completa de la prueba en varias fases.

Los resultados

Prueba 1: Creación y almacenamiento de pedidos

La primera prueba se diseñó para simular las características de rendimiento que cada tecnología presenta en el caso óptimo, en el que la acción a la que se llama realiza bastantes tareas. Para realizar bastantes tareas, la acción a la que se llama almacena pedidos en una base de datos, lo que implica escribir registros en dos tablas mediante una transacción.

El autor de la llamada crea una instancia de la siguiente clase Order.

[Serializable]  
public class Order  
{  
   public int OrderID;  
   public String CustomerID;  
   public int EmployeeID;  
   public DateTime OrderDate;  
   public Address ShippingAddress;  
   public Address BillingAddress;  
   public int ShipVia;  
   public decimal Freight;  
   public LineItem[] LineItems;  
}

La clase Order contiene un objeto secundario de tipo Address y una matriz de 20 LineItems:

[Serializable]  
public class Address  
{  
   public String Name;  
   public String Street;  
   public string City;  
   public string Region;  
   public string PostalCode;  
   public string Country;  
}  
  
[Serializable]  
public class LineItem  
{  
   public int ProductID;  
   public double UnitPrice;  
   public short Quantity;  
   public double Discount;  
}

Este objeto de datos se pasa del autor de la llamada al servidor durante la llamada del método y se serializa a través del cable mediante las diferentes tecnologías que estamos probando.

La implementación en el servidor es similar a la siguiente:

SqlConnection _conn;  
  
private void InitializeComponent()  
{  
   // ... large parts of generated code removed   
    _conn = new SqlConnection();  
   // ... large parts of generated code removed   
}  
  
public void StoreOrder(Order o)  
{  
   using (_conn)  
   {  
      _conn.Open();  
      using (SqlTransaction tx = _conn.BeginTransaction())  
      {  
         using (SqlCommand cmd = new SqlCommand(@"INSERT INTO Orders(EmployeeID, " +   
                      "CustomerID, OrderDate, RequiredDate, ShipVia, ShippedDate, " +   
                      "ShipName, Freight, ShipAddress, ShipCity, ShipRegion, " +   
                      "ShipCountry, ShipPostalCode) VALUES (@EmployeeID, @CustomerID, " +  
                      "@OrderDate, @RequiredDate, @ShipVia, @ShippedDate, @ShipName, " +    
                      "@Freight, @ShipAddress, @ShipCity, @ShipRegion, @ShipCountry, " +   
                      "@ShipPostalCode); SELECT @@IDENTITY", _conn,tx))  
         {  
            cmd.Parameters.Add("@EmployeeID", o.EmployeeID);  
            cmd.Parameters.Add("@CustomerID",o.CustomerID);  
            cmd.Parameters.Add("@OrderDate",o.OrderDate);  
            cmd.Parameters.Add("@RequiredDate",o.OrderDate.AddDays(10));  
            cmd.Parameters.Add("@ShipVia",o.ShipVia);  
            cmd.Parameters.Add("@ShippedDate",o.OrderDate.AddDays(5));  
            cmd.Parameters.Add("@ShipName",o.ShippingAddress.Name);  
            cmd.Parameters.Add("@Freight",o.Freight);  
            cmd.Parameters.Add("@ShipAddress",o.ShippingAddress.Street);  
            cmd.Parameters.Add("@ShipCity",o.ShippingAddress.City);  
            cmd.Parameters.Add("@ShipRegion",o.ShippingAddress.Region);  
            cmd.Parameters.Add("@ShipCountry",o.ShippingAddress.Country);  
            cmd.Parameters.Add("@ShipPostalCode",o.ShippingAddress.PostalCode);  
              
            decimal orderID = (decimal) cmd.ExecuteScalar();  
            o.OrderID = (int) orderID;  
         }  
  
         using (SqlCommand cmd = new SqlCommand(@"INSERT INTO [Order Details] (OrderID, " +  
                      "ProductID, UnitPrice, Quantity, Discount) VALUES (@OrderID, " +   
                      "@ProductID, @UnitPrice, @Quantity, @Discount)", _conn,tx))  
         {  
            cmd.Parameters.Add("@OrderID",SqlDbType.Int);  
            cmd.Parameters.Add("@ProductID",SqlDbType.Int);  
            cmd.Parameters.Add("@UnitPrice",SqlDbType.Money);  
            cmd.Parameters.Add("@Quantity",SqlDbType.SmallInt);  
            cmd.Parameters.Add("@Discount",SqlDbType.Real);  
  
            foreach (LineItem itm in o.LineItems)  
            {  
               cmd.Parameters["@OrderID"].Value = o.OrderID;  
               cmd.Parameters["@ProductID"].Value = itm.ProductID;  
               cmd.Parameters["@UnitPrice"].Value = itm.UnitPrice;  
               cmd.Parameters["@Quantity"].Value = itm.Quantity;  
               cmd.Parameters["@Discount"].Value = itm.Discount;  
               cmd.ExecuteNonQuery();  
            }  
         }  
           
         tx.Commit();  
      }  
      _conn.Close();  
   }  
}

Tras finalizar la ejecución de prueba, la lógica del servidor utiliza una segunda transacción para eliminar los registros insertados, proporcionando un "campo de juego uniforme" independientemente de las veces que se ejecute esta prueba.

Figura 1. Transferencia de un "pedido" entre equipos con una implementación del servidor real

Al observar los resultados de la prueba que muestra la figura 1, vemos que hay únicamente un 14% de diferencia entre ES a 73 CPS y los servicios Web ASP.NET a 63 CPS, y que la máxima diferencia entre el protocolo más rápido y el más lento es del 45%, lo que muestra claramente que las ventajas de un transporte sobre otro disminuyen a medida que la cantidad de tareas realizadas aumenta respecto al tiempo que se tarda en transportar los datos.

También hemos creado la correspondiente prueba DataSet ADO.NET, creando DataSets con tipo que contienen las DataTables que se definen como se muestra en la figura 2.

Figura 2. DataSet que representa un pedido de compra

Este DataSet se utiliza con un SqlDataAdapter generado que incluye SqlCommands similares a los que se muestran en los fragmentos de código anteriores.

Cuando el pedido se pasa del autor de la llamada al servidor como DataSet y, a continuación, se almacena, obtenemos los resultados que se muestran en la figura 3.

Figura 3. Almacenamiento de un pedido de compra como DataSet

Observe el importante impacto sobre el rendimiento al utilizar DataSets (aproximadamente una ralentización del 50%), junto con el hecho de que la diferencia entre protocolos disminuye aún más. También es importante observar que los resultados más lentos para pasar objetos de datos superan el mejor rendimiento obtenido al pasar DataSets de ADO.NET.

Esto nos demuestra claramente que pasar DataSets de ADO.NET entre niveles de un sistema supone una importante penalización del rendimiento.

Prueba 2: Recuperación de datos de productos de Northwind

El objetivo de esta prueba es ilustrar las características de rendimiento de cada tecnología cuando un servicio que no ha realizado un trabajo considerable devuelve una cantidad de datos relativamente importante.

Para modelar este escenario, hemos creado métodos que recuperan y devuelven una lista de registros de "productos" de la conocida base de datos de ejemplo "Northwind" de SQL Server.

Esperamos que las tecnologías de serialización binaria (ES/COM+ y Remoting binario/TCP) sean las que mejor realicen esta prueba; también esperamos que las tecnologías basadas en SOAP presenten niveles inferiores de rendimiento debido a las mayores cantidades de datos que se transportan, así como a unos mecanismos de serialización y deserialización más complejos.

En la primera prueba, hemos definido una clase [Serializable] que tiene miembros públicos compatibles con el serializador XML:

[Serializable] 
public class Product 
{ 
   public int ProductID; 
   public string ProductName; 
   public int SupplierID; 
   public int CategoryID; 
   public string QuantityPerUnit; 
   public decimal UnitPrice; 
   public short UnitsInStock; 
   public short UnitsOnOrder; 
   public short ReorderLevel; 
   public bool Discontinued; 
}

En la implementación en el servidor, abrimos una conexión de base de datos con SQL Server, ejecutamos una consulta respecto a la base de datos y, utilizando un SqlDataReader de ADO.NET, rellenamos un ArrayList que contiene 77 instancias de Product de esta clase. A continuación, la ArrayList se devuelve al autor de la llamada.

Los resultados se muestran en la figura 4.

Figura 4. Recuperación del catálogo de productos de Northwind como objetos

Estos resultados muestran que Enterprise Services (por encima de DCOM) y Remoting binario basado en TCP ofrecen niveles iguales de rendimiento para las llamadas no protegidas. Los resultados también muestran que los servicios Web ASP.NET ofrecen un rendimiento de aproximadamente el 62% del rendimiento de Enterprise Services y que los protocolos más lentos sólo permiten el 17% del número de llamadas por segundo en comparación con los más rápidos.

En esta y en todas las siguientes pruebas resulta evidente por qué no se suele recomendar la utilización de SoapFormatter de .NET Remoting para crear servicios SOAP: la pila del servicio Web ASP.NET es aproximadamente tres veces más rápida.

En la segunda aproximación a esta prueba, hemos implementado un método que devuelve los datos requeridos en un objeto DataSet de ADO.NET que se basa directamente en el diseño de tabla subyacente y rellena el DataTable del DataSet mediante un SqlDataAdapter. La definición de tabla se ilustra en la figura 5.

Figura 5. DataSet con tipo para obtener acceso al catálogo de productos

La figura 6 ilustra los resultados:

Figura 6. Recuperación del catálogo de productos de Northwind como un DataSet

En los resultados de esta prueba resulta evidente que devolver DataSets del servicio al autor de la llamada disminuye considerablemente el rendimiento: aproximadamente un 75% en el caso de los transportes binarios. Observe también que el rendimiento de los cuatro protocolos más rápidos es completamente idéntico, lo que implica que las cuatro tecnologías se vieron aceleradas por la serialización, la deserialización y el transporte del DataSet. Además, observe que el intervalo de rendimiento entre el más rápido (ASMX a 39 cps) y el más lento (Remoting HTTP/SOAP (IIS) seguridad integrada a 25 cps) se ven separados sólo por 14 cps: una mera disminución del 30%.

Obviamente, esto indica que aunque es cómodo utilizar DataSets para pasar información entre niveles de las aplicaciones, el rendimiento se ve considerablemente afectado al hacerlo. Volveremos a tratar este tema más adelante.

También es importante señalar que resulta más rápido repetir a través de un DataSet de ADO.NET, crear una colección de objetos de datos y serializarla en lugar de devolver el DataSet de ADO.NET al autor de la llamada. Si éste fuera un sistema real, implementado para pasar DataSets entre servidor y autor de la llamada, podríamos hasta multiplicar por cuatro el rendimiento de esta parte del sistema con un pequeño esfuerzo.

Prueba 3: Recuperación de información sobre clientes

En la siguiente prueba, queríamos examinar las características de rendimiento relativo de cada tecnología al transferir una cantidad muy pequeña de datos del servidor al cliente recuperando un único registro de cliente de la base de datos de ejemplo "Northwind" de SQL Server.

Hemos creado la siguiente clase Customer [serializable] para transportar los datos recuperados del cliente al servidor:

[Serializable] 
public class Customer 
{ 
   public String CustomerID; 
   public String CompanyName; 
   public String ContactName;  
   public String ContactTitle; 
   public string Address;  
   public string City; 
   public string Region; 
   public string PostalCode;  
   public string Country; 
   public string Phone; 
   public string Fax; 
}

A continuación, vemos una parte de la implementación en el servidor que utiliza un SqlDataReader para rellenar una instancia de la clase Customer:

public Customer GetCustomer(string id) 
{ 
   using (SqlConnection conn = new SqlConnection(...)) 
   { 
      conn.Open(); 
 
      String sql = "SELECT CustomerID, CompanyName, ContactName, " 
                   "ContactTitle, Address, City, Region, " + 
                   "PostalCode, Phone, Fax, Country FROM " +  
                   "Customers WHERE (CustomerID = @CustomerID)"; 
 
      using (SqlCommand cmd = new SqlCommand(sql,conn)) 
      { 
         cmd.Parameters.Add("@CustomerID", id); 
         SqlDataReader rdr = cmd.ExecuteReader(); 
         if (rdr.Read()) 
         { 
            Customer c = new Customer(); 
            c.CustomerID = (string) rdr[0]; 
            c.CompanyName = (String) rdr[1]; 
            c.ContactName = (String) rdr[2]; 
            c.ContactTitle = (String) rdr[3]; 
            c.Address = (String) rdr[4]; 
            c.City = (String) rdr[5]; 
            c.Region = rdr.IsDBNull(6) ? " : rdr[6] as string; 
            c.PostalCode = (String) rdr[7]; 
            c.Phone = (String) rdr[8]; 
            c.Fax = (String) rdr[9]; 
            c.Country = (String) rdr[10]; 
            return c; 
         } 
         else 
         { 
            return null; 
         } 
      } 
   } 
}

Los resultados de nuestra comparación de rendimiento aparecen en la figura 7.

Figura 7. Recuperación de los datos del cliente como objeto

Estos resultados resaltan con mayor claridad las diferencias de rendimiento que hay entre las diferentes tecnologías subyacentes. Estas diferencias resultan especialmente visibles en esta prueba, ya que el trabajo que se realiza para recuperar y devolver un único registro constituye un porcentaje mucho más pequeño del coste global de la llamada y, por tanto, el coste del transporte desempeña un papel más importante. Por tanto, ya que SOAP/HTTP tiene un coste de transporte superior a binario/DCOM, los transportes SOAP muestran niveles de productividad muy inferiores a los mecanismos binarios.

A continuación, hemos probado la misma operación devolviendo un DataSet con tipo, como se muestra en la figura 8.

Figura 8. DataSet con tipo para obtener acceso a la información del cliente

Este DataSet se rellena mediante una implementación en el servidor similar a la siguiente:

SqlDataAdapter _customerAdapter; 
SqlCommand _customerSelect; 
SqlConnection _conn; 
 
private void InitializeComponent() 
{ 
   // ... large parts of generated code removed  
 
    _conn = new SqlConnection(); 
    _customerAdapter = SqlDataAdapter(); 
    _customerSelect = SqlCommand(); 
 
    _customerSelect.CommandText = "SELECT CustomerID, CompanyName, " + 
               "ContactName, ContactTitle, Address, City, Region, " + 
               "PostalCode, Phone, Fax, Country FROM Customers WHERE " +  
               "(CustomerID = @CustomerID)"; 
 
_customerSelect.Connection = _conn; 
 
_customerSelect.Parameters.Add(new SqlParameter("@CustomerID",  
               SqlDbType.NVarChar, 5, "CustomerID")); 
 
    _customerAdapter.SelectCommand = this.sqlSelectCommand3; 
 
    _customerAdapter.TableMappings.AddRange(new DataTableMapping[] { 
           new DataTableMapping("Table", "Customers", new DataColumnMapping[] { 
                  new DataColumnMapping("CustomerID", "CustomerID"), 
                  new DataColumnMapping("CompanyName", "CompanyName"), 
                  new DataColumnMapping("ContactName", "ContactName"), 
                  new DataColumnMapping("ContactTitle", "ContactTitle"), 
                  new DataColumnMapping("Address", "Address"), 
                  new DataColumnMapping("City", "City"), 
                  new DataColumnMapping("Region", "Region"), 
                  new DataColumnMapping("PostalCode", "PostalCode"), 
                  new DataColumnMapping("Phone", "Phone"), 
                  new DataColumnMapping("Fax", "Fax"), 
                  new DataColumnMapping("Country", "Country")})}); 
 
   // ... large parts of generated code removed  
} 
 
 
public PerfTestDataSet GetCustomerAsDataset(string id) 
{ 
   using (_conn) 
   { 
      _conn.Open(); 
      customerAdapter.SelectCommand.Parameters["@CustomerID"].Value = id; 
       
      PerfTestDataSet ds = new PerfTestDataSet(); 
      _customerAdapter.Fill(ds,"Customers"); 
      return ds; 
   } 
}

Al ejecutar este código en nuestro marco de trabajo de prueba, hemos obtenido los resultados que se muestran en la figura 9.

Figura 9. Recuperación de los datos del cliente como un DataSet

De manera similar a las pruebas anteriores, resulta evidente que intercambiar DataSets de ADO.NET afecta negativamente al rendimiento y la diferencia en la productividad para todas las tecnologías resulta menor que cuando se devolvían objetos serializados, lo que ilustra que los DataSets de ADO.NET afectan a la productividad.

Rendimiento de .NET Framework 2.0

En el momento de redactar este artículo, Microsoft trabaja para finalizar .NET Framework 2.0 (anteriormente con el código "Whidbey") que incluye un gran número de mejoras y nuevas posibilidades entre las que se incluyen:

  • Compatibilidad total con equipos basados en x64 y IA64

  • Compatibilidad con transacciones completamente nuevas mediante System.Transactions

  • Numerosas mejoras a System.Net entre las que se incluye detección de la conectividad y compatibilidad con servidores proxy

  • Importantes mejoras para Windows Forms y Web Forms

  • Infraestructura de implementación automática de aplicaciones "ClickOnce"

Además de las características nuevas y mejoradas que incluye .NET Framework 2.0, se ha hecho un importante esfuerzo para mejorar considerablemente el rendimiento y el uso de la memoria en numerosas áreas, entre las que se incluye BCL, serialización XML, productividad de trabajo en red, ADO.NET, ASP.NET, etc.

Se pueden ver los primeros ejemplos de estas mejoras de rendimiento y productividad en los siguientes artículos:

Plataformas .NET Framework 2.0 Beta 2, .NET Framework 1.1 y Sun Java 1.5

WS Test 1.1 Resultados de la prueba comparativa para .NET Framework 2.0, .NET 1.1, Sun JWSDP 1.5 e IBM WebSphere 6.0

Se publicarán más artículos de análisis y comparación del rendimiento durante los próximos meses a medida que .NET Framework 2.0 prosiga su trayectoria hacia el lanzamiento al mercado. Para mantenerse actualizado con estos artículos, visite los siguientes recursos en línea:

Conclusiones

Los resultados de las pruebas reales aparecen ilustradas en la tabla 1.

Llamadas por segundo (redondeadas)

Enterprise Services

Servicios Web ASP.NET

.NET Remoting TCP binario

Prueba 1: Almacenamiento de pedidos

.

.

.

a) Datos serializados

73

63

72

b) DataSet

35

34

34

Prueba 2: Recuperación de productos

.

.

.

a) Datos serializados

147

93

149

b) DataSet

39

39

39

Prueba 3: Recuperación de clientes

.

.

.

a) Datos serializados

618

289

682

b) DataSet

90

83

91

Estos resultados muestran las características de rendimiento que se puede esperar de aplicaciones reales, así como el hecho de que la diferencia entre los servicios Web (que suelen considerarse muy lentos) y DCOM (que es claramente una de las tecnologías de aplicaciones distribuidas más rápidas de esta prueba) es en realidad muy pequeña para aplicaciones reales.

Nuestras observaciones sobre las tecnologías que se están probando se tratan con mayor detalle en la siguiente sección, pero aparecen resumidas a continuación:

  • Mientras que ASMX no es en absoluto la tecnología más rápida disponible en la actualidad, su rendimiento es más que adecuado para la mayoría de los escenarios empresariales. Si, además, tenemos en cuenta que los servicios ASMX son fáciles de ampliar y ofrecen una gran variedad de ventajas adicionales, como interoperabilidad y compatibilidad con versiones futuras, su primera opción para crear servicios hoy en día es ASMX.

  • Si el rendimiento absoluto es de máxima importancia, deberán utilizarse los componentes de Enterprise Services para crear las partes del sistema cuyo rendimiento sea de mayor importancia. COM+ obtuvo los mejores resultados globales y es un entorno seguro, protegido y confiable para alojar componentes distribuidos. ES/COM+ también se integrará bien con los servicios Indigo y será relativamente sencillo convertir componentes de ES a los servicios Indigo.

  • Aunque .NET Remoting obtiene buenos resultados cuando se utiliza la serialización binaria a través de TCP, su rendimiento disminuye cuando los componentes de Remoting se alojan en IIS o cuando se envían y reciben mensajes SOAP. Si, además, tenemos en cuenta que los componentes de .NET Remoting sólo interoperarán con extremos de .NET Remoting, le recomendamos que considere ASMX o ES antes que Remoting siempre que sea posible.

Una conclusión muy importante que hay que extraer de estos resultados es que si la cantidad de trabajo realizado en el servidor no supone un porcentaje considerable de la duración global de cada llamada, el tiempo de transporte será una parte importante del tiempo de la llamada. Si pasa de un transporte "rápido" (como DCOM en COM+) a un transporte más "costoso" (como SOAP/HTTP en ASMX) es posible que el rendimiento se vea considerablemente afectado. Por tanto, nuestro consejo es que realice tanto trabajo como sea posible en el servidor para cada llamada a método y evite realizar viajes innecesarios a través de la red.

Las ventajas de rendimiento de estas tecnologías sobre otras disminuyen a medida que aumenta la cantidad de trabajo que realiza el servicio al que se llama. Esta observación ha sido señalada en numerosos artículos, entre ellos Rendimiento de .NET Enterprise Services.

También resulta evidente a partir de estas pruebas que las diferencias de rendimiento entre estas tecnologías son menores que las diferencias entre decisiones específicas de la aplicación, como el uso de DataSets o estructuras serializadas.

Aunque en este artículo nos hemos centrado principalmente en las cifras de rendimiento, éste no es el único factor que hay que tener en cuenta para planear los proyectos de desarrollo. También entran en juego otros factores como la seguridad, la escalabilidad, la administración, la productividad de los desarrolladores, la interoperabilidad y el rumbo de las tecnologías distribuidas de Microsoft. El artículo sobre el desarrollo actual de los servicios distribuidos ofrece orientación prescriptiva sobre cómo elegir la tecnología más adecuada para cada momento y lugar, así como lo que nos depara el futuro.

Recomendaciones

En función de los resultados de estas pruebas y de acuerdo con la dirección de las futuras tecnologías y las prácticas recomendadas, podrá crear sistemas que no sean propensos a presentar problemas de rendimiento si tiene en cuenta las siguientes recomendaciones:

Utilice ASMX siempre que sea posible

Para ofrecer el alcance más amplio a sus servicios, considere la posibilidad de publicar los servicios mediante ASMX siempre que sea posible, lo que permitirá a cualquier sistema que pueda comunicarse en SOAP mediante HTTP llamar a su servicio, independientemente de la plataforma, dispositivo o lenguaje que esté ejecutando el sistema o en el que se haya implementado. Como puede ver en los resultados anteriores, ASMX obtiene resultados admirables en numerosos escenarios. Incluso en nuestro equipo con un único procesador llamado por una aplicación con un único subproceso, ASMX es capaz de procesar unas 63 operaciones importantes por segundo, sólo 10 llamadas por segundo menos que el componente ES equivalente. En un entorno de producción, puede esperar un rendimiento considerablemente mayor de un único equipo que aloja servicios ASMX, por lo que el rendimiento de ASMX no debería obstaculizar el uso de esta importante tecnología.

Los servicios Web presentan otras características y funciones útiles que incluyen (entre otras):

  • Escalabilidad: resulta muy sencillo escalar un servicio Web mediante una tecnología de equilibrio de carga como Windows Network Load Balancing o dispositivos de hardware de proveedores como Cisco y F5. Volveremos más adelante a este tema.

  • Disponibilidad: los servicios Web ASMX se pueden configurar para que tengan una alta disponibilidad mediante una combinación de tecnologías como el equilibrio de carga, combinado con las eficaces capacidades de la infraestructura IIS6 creada en Windows 2003 Server (como reciclaje automático y reinicio de los servicios fallidos).

  • Interoperabilidad: los servicios Web se encuentran en el núcleo del movimiento que intenta normalizar los protocolos de comunicaciones interoperables, seguros, confiables y mediante transacciones, lo que permite que sistemas dispares y heterogéneos puedan comunicarse libremente.

  • Productividad: la creación de servicios Web ASMX es muy sencilla para la mayoría de los desarrolladores si se utilizan juiciosamente unos cuantos atributos y se siguen algunas recomendaciones.

Utilice ASMX para los servicios Web

Hay numerosos motivos por los que ASMX es una plataforma excelente para crear e implementar servicios como se describe en el artículo de orientación prescriptiva y, como hemos visto en los resultados de este artículo, ASMX suele obtener mejores resultados que Remoting cuando se trata de SOAP.

También es importante señalar que aunque .NET Remoting admite SOAP/HTTP (mediante SoapFormatter y HttpChannel) hemos recomendado no utilizar Remoting para exponer servicios Web. El SoapFormatter de .NET Remoting utiliza codificación RPC, que ya no es la manera estándar de codificar SOAP (documento-literal es el futuro mecanismo de codificación estándar que utilizarán las tecnologías y las plataformas de la mayoría de los proveedores); por tanto, la interoperabilidad con los servicios Remoting se verá muy limitada.

Elija servicios Web para lograr escalabilidad

Algo que no se ha ilustrado anteriormente, pero que es de gran importancia para tratar este tema, es que los servicios Web se comunican principalmente a través de HTTP, una tecnología de comunicaciones sin estado a la que es fácil aplicar equilibrio de carga. Por tanto, también es posible aplicar equilibrio de carga sin estado a componentes de Remoting mediante TCP o HTTP (es decir, alojados en IIS), aunque esto puede volverse complejo y problemático si es necesario utilizar el estado de la sesión.

Para aplicar equilibrio de carga a componentes de ES/COM+, deberá utilizar el equilibrio de carga de componentes (CLB), una característica de Application Center 2000. Desgraciadamente, AppCenter 2000 entra en soporte extendido en julio de 2006 y el soporte termina en 2011. Por tanto, para tener que cambiar la arquitectura de los sistemas bastante antes de 2011 o dejar de depender de CLB, es más que recomendable evitar esta tecnología en el desarrollo y, por el contrario, migrar cuanto antes a otras tecnologías. Una buena estrategia de migración es afrontar los componentes actuales COM+ con servicios Web ASMX, que sencillamente pasan las llamadas directamente hasta el componente COM+ y aplicar equilibrio de carga a los servicios Web como se ha descrito anteriormente.

Utilice Enterprise Services únicamente dentro de los servicios

.NET Enterprise Services es una capa de .NET Framework que ofrece acceso (y compatibilidad) con los numerosos servicios que ofrece COM+. Si necesita algunas de las variadas características que ofrecen los servicios COM+, como transacciones distribuidas que abarcan varios objetos o servicios, seguridad muy detallada, JITA y agrupación de objetos, deberá optar por Enterprise Services. Enterprise Services y COM+ son tecnologías probadas a fondo y muy optimizadas que ofrecen llamadas muy rápidas y con baja latencia entre procesos y entre equipos.

Sin embargo, le recomendamos que no exponga en general los componentes de Enterprise Services y que utilice esta tecnología únicamente dentro de los límites de su servicio. Si desea ofrecer acceso a su servicio, le aconsejamos que exponga las capacidades del servicio mediante servicios Web utilizando ASMX. Si dispone de una base de código ES/COM+ establecida, le sugerimos que afronte los servicios COM+ con servicios Web ASMX siempre que sea posible.

Considere recurrir a una infraestructura alojada en vez de crear la suya propia

Como hemos visto anteriormente, ASP.NET ofrece unos servicios Web con un excelente rendimiento que son muy interoperables y que también se benefician de las grandes capacidades de alojamiento que ofrece IIS: en concreto IIS6 en Windows 2003 Server.

COM+ ofrece el rendimiento de componentes más rápido en la plataforma Microsoft junto con un entorno de alojamiento probado, confiable, seguro y protegido para sus componentes de COM+ y Enterprise Services. También ofrece compatibilidad con transacciones distribuidas, seguridad (autenticación y cifrado), confiabilidad, disponibilidad, servicios administrados y es una excelente opción para alojar sistemas basados en componentes complejos dentro de su servicio.

Aunque .NET Remoting con serialización binaria a través de TCP también ofrece un excelente rendimiento, no ofrece ningún entorno de alojamiento con las características de seguridad, confiabilidad, disponibilidad o facilidad de administración listas para usar. Para alojar componentes de Remoting que utilicen TCP, deberá escribir su propia aplicación de alojamiento (seguro, escalable y confiable), algo que no es tarea fácil. Si desea utilizar Remoting a través de HTTP, también puede utilizar IIS como host, pero como puede ver, alojar su componente de Remoting en IIS y comunicarse mediante SOAP/HTTP afecta considerablemente al rendimiento de Remoting, con frecuencia hasta el punto de que se obtienen mejores resultados con ASMX.

Por tanto, le recomendamos que considere ofrecer sus servicios en ASMX alojado en IIS o componentes de Enterprise Services en COM+, en vez de utilizar Remoting, siempre que sea posible.

Evite pasar DataSets entre servicios

En nuestras pruebas, afecta mucho más al rendimiento la manera en que los servicios y los autores de las llamadas intercambian los datos (como DataSets o estructuras serializadas) que la elección de una tecnología determinada de sistemas distribuidos en lugar de otra.

Desde el punto de vista del rendimiento, le recomendamos que limite el uso de DataSets como mecanismo de transferencia de datos a las partes de la aplicación donde son verdaderamente necesarios y que utilice estructuras [serializables] siempre que sea posible.

Los DataSets ADO.NET ofrecen una manera estupenda de recuperar, manipular, ordenar y dar forma a los datos, almacenarlos para uso sin conexión y sincronizar los cambios con una base de datos central. Si este es un requisito de la aplicación, entonces será una opción perfectamente válida. En .NET Framework 1.x, los valores de DataSet siempre se serializan en XML (incluso si se indica que desea serializarlos como binarios o utilizarlos con ES o Remoting) y también contienen el XSD que describe los datos. Por supuesto, esto afecta al rendimiento.

Además, recuerde que los DataSets son una tecnología específica de .NET y, por tanto, limitarán considerablemente la interoperabilidad con otras plataformas, las cuales no son necesariamente capaces de serializar y analizar los datos que contienen los DataSets serializados.

Puede obtener una considerable mejora del rendimiento si, en su lugar, intercambia estructuras de datos serializados. El marco de trabajo de serialización de XML y el formato de tiempo de ejecución integrado lo hacen muy sencillo, como se ve en las pruebas anteriores.

Utilice el uso compartido de conexiones autenticadas

Todas las pruebas que utilizan Internet Information Server como host junto con la seguridad integrada se han configurado para ejecutarse con las opciones useAuthenticatedConnectionSharing y useUnsafeAuthenticatedConnectionSharing que están disponibles para clientes ASP.NET y .NET Remoting. Esta configuración permite al cliente y al servidor reutilizar una conexión autenticada NTLM existente.

Puede ver los resultados de rendimiento cuando establecimos esta opción en la figura 10 durante las pruebas presentadas originalmente en la figura 1 (almacenando un pedido de compra como objetos). Observe que esta configuración sólo surte efecto si utiliza Internet Information Server (IIS) como servidor y establece "Windows In Security" en la configuración del directorio virtual.

La columna Web Q&A: transformaciones del almacenamiento en caché, uso compartido de conexión y mucho más del número de septiembre de 2004 de MSDN Magazine trata estas ventajas e inconvenientes.

Figura 10. Impacto de UnsafeAuthenticatedConnectionSharing

Puede utilizar la seguridad integrada de Windows junto con esta configuración en servicios Web ASP.NET como éste:

MyWebService svc = new MyWebService();
svc.Credentials = System.Net.CredentialCache.DefaultCredentials;
svc.UnsafeAuthenticatedConnectionSharing = true;

Y con .NET Remoting como éste:

IMyRemote rem = (IMyRemote) Activator.GetObject(typeof(IMyRemote), "HTTP://...");
IDictionary snkprops = ChannelServices.GetChannelSinkProperties(rem);
snkprops["unsafeauthenticatedconnectionsharing"] = true;

Apéndice A: Línea de base sintética, prueba del método vacío

Esta prueba determina la línea base de las diferencias de rendimiento entre las tecnologías subyacentes que se están examinando. Estas pruebas realizan llamadas respecto a acciones que no aceptan ningún parámetro, no realizan ningún trabajo y no devuelven ningún resultado. La implementación en el servidor es así de sencilla:

public void TransferEmpty()
{
   // do nothing
}

Nota   Es importante recordar que las cifras de la línea de base sintética se presentan únicamente para ilustrar los niveles relativos de rendimiento de la infraestructura de comunicaciones de cada una de las tecnologías que se examinan y no refleja las características de rendimiento esperadas en los sistemas reales.

Figura 11. Llamada a un método sin parámetros entre procesos (línea de base sintética)

Los resultados de nuestras pruebas de la figura 11 coinciden con bastante exactitud con las ideas previas: ES ofrece con diferencia el mejor rendimiento debido a su dependencia de COM+ y DCOM y la infraestructura de comunicaciones incorporada LPC (llamada ligera a procedimientos). Los protocolos por cable de .NET Remoting aparecen en segundo lugar y los servicios Web ASP.NET en el tercero, que son más rápidos que los componentes de .NET Remoting alojados en IIS.

En segundo lugar, hemos ejecutado esta prueba entre equipos. Hemos redireccionado la ASP.NET generada estableciendo su propiedad "Url", exportado un proxy de aplicaciones para los componentes de COM+/Enterprise Services y utilizado Activator.GetObject() para la parte de .NET Remoting de esta prueba. Los resultados están muy en la línea de las pruebas anteriores, pero con números ligeramente inferiores de llamadas por segundo debido a los viajes de red implicados:

Figura 12. Llamada a un método vacío sin parámetros entre equipos (línea de base sintética)

Observe que el viaje de red entre equipos ha acelerado básicamente los transportes más rápidos (ES y Remoting binario/TCP), mientras que apenas ha afectado a los transportes más lentos. Esto demuestra la eficacia con que se comparan los mecanismos de comunicación entre procesos de COM+ con respecto a las tecnologías creadas fundamentalmente para servir el tráfico de la red (es decir, IIS y ASMX).

Es importante recordar, como ya hemos mencionado anteriormente, que esta prueba es muy artificial y únicamente sirve para ilustrar las capacidades de los transportes.

Apéndice B: Resultados detallados de las pruebas

Almacenar pedido como objeto

Prueba

Promedio de llamadas/segundo

Desviación est.

Enterprise Services

73

0,39

Enterprise Services (aut.)

73

0,34

Remoting TCP/binario

72

2,71

Remoting HTTP/binario

68

0,86

Remoting HTTP/binario (IIS)

66

0,31

Servicios Web ASP.NET

63

2,71

Remoting HTTP/binario (IIS) contraseña

63

0,39

Remoting TCP/SOAP

56

1,97

Remoting HTTP/SOAP

53

0,57

Remoting HTTP/binario (IIS) integrada

51

0,28

Remoting HTTP/SOAP (IIS)

50

0,16

Servicios Web ASP.NET: integrada

50

0,30

Remoting HTTP/SOAP (IIS) contraseña

49

0,29

Remoting HTTP/SOAP (IIS) integrada

40

0,84

Almacenamiento de pedido como DataSet

Prueba

Promedio de llamadas/segundo

Desviación est.

Enterprise Services

35

0,54

Enterprise Services (aut.)

35

0,51

Servicios Web ASP.NET

34

0,43

Remoting TCP/binario

34

0,85

Remoting HTTP/binario

32

0,77

Remoting HTTP/binario (IIS)

32

1,10

Remoting TCP/SOAP

32

0,77

Remoting HTTP/binario (IIS) contraseña

31

1,47

Remoting HTTP/SOAP

30

0,68

Remoting HTTP/SOAP (IIS)

30

0,48

Remoting HTTP/SOAP (IIS) contraseña

30

0,46

Servicios Web ASP.NET: integrada

29

0,37

Remoting HTTP/binario (IIS) integrada

28

0,37

Remoting HTTP/SOAP (IIS) integrada

26

0,31

Carga de productos como objetos

Prueba

Promedio de llamadas/segundo

Desviación est.

Remoting TCP/binario

149

3,05

Enterprise Services

147

2,29

Enterprise Services (aut.)

146

2,49

Remoting HTTP/binario

118

2,13

Remoting HTTP/binario (IIS)

114

0,63

Remoting HTTP/binario (IIS) contraseña

106

1,19

Servicios Web ASP.NET

93

1,04

Remoting HTTP/binario (IIS) integrada

76

0,81

Servicios Web ASP.NET: integrada

67

0,35

Remoting TCP/SOAP

33

0,34

Remoting HTTP/SOAP

30

0,32

Remoting HTTP/SOAP (IIS)

30

0,25

Remoting HTTP/SOAP (IIS) contraseña

29

0,16

Remoting HTTP/SOAP (IIS) integrada

26

0,14

Carga de productos como DataSet

Prueba

Promedio de llamadas/segundo

Desviación est.

Servicios Web ASP.NET

39

0,12

Enterprise Services

39

0,26

Enterprise Services (aut.)

39

0,21

Remoting TCP/binario

39

1,16

Remoting HTTP/binario (IIS)

36

0,24

Remoting HTTP/binario

35

1,10

Remoting HTTP/binario (IIS) contraseña

37

0,17

Servicios Web ASP.NET: integrada

33

0,09

Remoting HTTP/binario (IIS) integrada

31

0,21

Remoting TCP/SOAP

30

1,27

Remoting HTTP/SOAP (IIS)

29

0,12

Remoting HTTP/SOAP

28

1,07

Remoting HTTP/SOAP (IIS) contraseña

28

0,06

Remoting HTTP/SOAP (IIS) integrada

25

0,08

Carga de cliente como objeto

Prueba

Promedio de llamadas/segundo

Desviación est.

Remoting TCP/binario

682

12,32

Enterprise Services

618

13,78

Enterprise Services (aut.)

616

7,76

Remoting HTTP/binario

406

7,84

Remoting TCP/SOAP

359

11,62

Remoting HTTP/binario (IIS)

324

4,26

Servicios Web ASP.NET

289

2,68

Remoting HTTP/SOAP

267

6,18

Remoting HTTP/binario (IIS) contraseña

261

2,39

Remoting HTTP/SOAP (IIS)

214

2,84

Remoting HTTP/SOAP (IIS) contraseña

186

0,81

Remoting HTTP/binario (IIS) integrada

134

0,95

Servicios Web ASP.NET: integrada

130

0,67

Remoting HTTP/SOAP (IIS) integrada

112

0,55

Carga de cliente como DataSet

Prueba

Promedio de llamadas/segundo

Desviación est.

Remoting TCP/binario

91

2,69

Enterprise Services

90

0,30

Enterprise Services (aut.)

90

0,26

Servicios Web ASP.NET

83

0,24

Remoting HTTP/binario

80

0,67

Remoting TCP/SOAP

78

1,04

Remoting HTTP/binario (IIS)

78

0,22

Remoting HTTP/binario (IIS) contraseña

75

0,26

Remoting HTTP/SOAP

71

0,92

Remoting HTTP/SOAP (IIS)

67

0,34

Remoting HTTP/SOAP (IIS) contraseña

64

0,20

Servicios Web ASP.NET: integrada

62

0,14

Remoting HTTP/binario (IIS) integrada

59

0,15

Remoting HTTP/SOAP (IIS) integrada

52

0,13

Mensaje vacío, a través de procesos

Prueba

Promedio de llamadas/segundo

Desviación est.

Enterprise Services

14687

52,66

Enterprise Services (aut.)

12293

31,71

Remoting TCP/binario

3538

38,87

Remoting HTTP/binario

1069

8,05

Remoting TCP/SOAP

1075

11,87

Remoting HTTP/SOAP

612

7,88

Remoting HTTP/binario (IIS)

589

1,83

Servicios Web ASP.NET

517

1,44

Remoting HTTP/binario (IIS) integrada

451

1,19

Remoting HTTP/binario (IIS) contraseña

421

0,90

Remoting HTTP/SOAP (IIS)

406

1,76

Servicios Web ASP.NET: integrada

403

0,76

Remoting HTTP/SOAP (IIS) integrada

336

0,57

Remoting HTTP/SOAP (IIS) contraseña

321

0,37

Mensaje vacío, a través de equipos

Prueba

Promedio de llamadas/segundo

Desviación est.

Enterprise Services (aut.)

3068

25,35

Enterprise Services

3048

38,24

Remoting TCP/binario

2609

77,28

Remoting TCP/SOAP

760

31,65

Remoting HTTP/binario

704

8,00

Remoting HTTP/binario (IIS)

479

2,60

Remoting HTTP/SOAP

413

10,63

Servicios Web ASP.NET

399

2,00

Remoting HTTP/binario (IIS) contraseña

351

1,98

Remoting HTTP/SOAP (IIS)

309

1,38

Remoting HTTP/SOAP (IIS) contraseña

252

1,25

Remoting HTTP/binario (IIS) integrada

156

0,52

Servicios Web ASP.NET: integrada

150

0,57

Remoting HTTP/SOAP (IIS) integrada

133

0,28

Apéndice C: Notas sobre la aplicación de prueba

Ejecución de la aplicación de prueba

Puede descargar la aplicación de prueba en la ubicación especificada al comienzo de este artículo. Para realizar estas pruebas en su propio hardware, necesita disponer de un mínimo de dos equipos: un cliente y un servidor. Además, deberá disponer de acceso a una instalación de SQL Server que incluya la base de datos de ejemplo Northwind. Encontrará una guía detallada sobre el modo de implementar, configurar y ejecutar este conjunto de pruebas en el archivo README.TXT que se incluye en el archivo ZIP que contiene el código fuente.

Idea interesante: la aplicación de prueba es agnóstica respecto a la tecnología

Observará en la aplicación de prueba que es posible crear aplicaciones que sean agnósticas respecto al transporte. En la aplicación de ejemplo, encontrará un método Test.CreateProxy() que crea una referencia a un servicio remoto y devuelve un contenedor del cliente (un proxy de servicio Web o el correspondiente TransparentProxy en el caso de ES y .NET Remoting) que implementa una determinada interfaz. Al llamar a este método, se puede especificar el protocolo de transporte que se utilizará, la configuración de seguridad, formateadores, etc. El resto de la aplicación no se preocupa del protocolo subyacente, lo que permite crear una aplicación agnóstica respecto al protocolo y elegir los protocolos adecuados en función del entorno de la aplicación.

Apéndice D: Configuración de software y hardware

Las siguientes pruebas se han realizado con tres equipos: un cliente, un servidor de aplicaciones y un servidor de base de datos. Todas las pruebas se han realizado con la suficiente cantidad de memoria física disponible para evitar una paginación innecesaria.

Entorno de la aplicación

  • Cliente: aplicación de consola con un único subproceso, escrita en C#, generada con Visual Studio.NET 2003 en modo Release.

  • Servicio Web ASP.NET ejecutándose en IIS 6.0 en Windows Server 2003.

  • Componentes de Enterprise Services con diferentes configuraciones (activación de biblioteca y activación de servidores, sin autenticación y con autenticación de llamadas) ejecutándose en COM+ 1.5 en Windows Server 2003.

  • Un servidor .NET Remoting independiente como aplicación de consola en C#, escrita en C#, generada con Visual Studio .NET 2003 en modo Release.

Entorno de la infraestructura

Cliente:

  • CPU: Intel P4 a 2,4 GHz

  • Memoria: 768 MB

  • SO: Windows Server 2003 Standard Edition (con todas las actualizaciones hasta junio de 2004)

  • .NET Framework 1.1 SP1

Servidor de aplicaciones:

  • CPU: Intel P4 a 2,8 GHz

  • Memoria: 1024 MB

  • SO: Windows Server 2003 Standard Edition

  • .NET Framework 1.1 SP1

Servidor de base de datos:

  • CPU: Intel P4 Prescott a 2,8 GHz, con HT, 800 MHz FSB

  • Memoria: 1024 MB

  • SO: Windows Server 2003 Standard Edition

  • Base de datos: SQL Server 2000 Enterprise Edition (con SP3A)

  • .NET Framework 1.1 SP1

Red:

  • 100 Mbps, Ethernet conmutada

Mostrar:
© 2016 Microsoft