Rendimiento de servicios web de ASP.NET, servicios empresariales y comunicación remota de .NET

 

Ingo Rammer
thinktecture.

Richard Turner
Program Manager
Grupo de sistemas distribuidos de Microsoft

Agosto de 2005

Resumen: Compare y contraste las características de rendimiento de los servicios web ASP.NET de la vida real, los componentes de .NET Enterprise Services y los componentes de .NET Remoting, y obtenga recomendaciones sobre cómo usar mejor estas tecnologías. (34 páginas impresas)

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

Contenido

Introducción
Objetivos
   Esto no es una prueba comparativa
   Pruebas
Resultado
   Prueba 1: Crear y almacenar pedidos
   Prueba 2: Recuperar los datos de producto de Northwind
   Prueba 3: Recuperar información del cliente
Rendimiento de .NET Framework 2.0
Conclusiones
   Recomendaciones
Apéndice A: Línea base sintética- Prueba de método vacío
Apéndice B: Resultados detallados de pruebas
   Almacenar pedido como objeto
   Almacenar pedido como DataSet
   Cargar productos como objetos
   Cargar productos como DataSet
   Cargar cliente como objeto
   Cargar cliente como DataSet
   Mensaje vacío, cross-process
   Mensaje vacío. Entre máquinas
Apéndice C: Probar notas de la aplicación
   Ejecución de la aplicación de prueba
   Factoid interesante: la aplicación de prueba es independiente de la tecnología.
Apéndice D: Configuración de software y hardware
   Entorno de aplicación
   Entorno de infraestructura

Introducción

Aunque el rendimiento absoluto es de gran preocupación para varias áreas de tecnología (dispositivos, controladores de hardware, servicios de vida y atención sanitaria, ciertos sistemas financieros), estos tienden a estar entre las minorías. La mayoría de los objetivos principales de las aplicaciones empresariales son "corrección", "tiempo de entrega" y la necesidad de ser tan rápido como sea necesario, pero no más. El costo y el esfuerzo de las aplicaciones de ingeniería que ofrecen un rendimiento absolutamente máximo posible pueden ser enormes; el tiempo y la aptitud considerables necesarios para el rendimiento máximo a menudo no son necesarios para muchos sistemas empresariales. Sin embargo, aunque el rendimiento máximo absoluto suele ser excesivo, garantizar un buen rendimiento general del sistema sigue siendo un objetivo para la mayoría de las empresas que quieran maximizar su rentabilidad de la inversión.

En estas notas del producto, proporcionaremos un análisis comparativo de los niveles de rendimiento relativos de componentes o servicios reales hospedados en cada una de las tres tecnologías de servicios o componentes distribuidos disponibles en .NET:

• .NET Enterprise Services (ES) hospedado en COM+
• servicios web de ASP.NET (ASMX) hospedados en IIS
• Comunicación remota de .NET hospedada en IIS y hosts personalizados

(Nota El rendimiento de las API COM de System.Messaging frente a MSMQ se abordará en el documento Rendimiento de System.Messaging ).

Objetivos

Hay un debate sin fin sobre "que es la tecnología de aplicaciones distribuidas de Microsoft más rápida" o declaraciones que "<insertar el nombre de la tecnología aquí> es demasiado lento para que lo usemos". El objetivo principal de este documento es abordar y aclarar muchas de las preocupaciones, ideas erróneas, inexactitudes y desinformación relacionada con el rendimiento de las tecnologías distribuidas de Microsoft.

Nuestro objetivo es erradicar muchas ideas erróneas sobre las características relativas de rendimiento de cada una de las tecnologías distribuidas de componentes y servicios de Microsoft, y proporcionar un conjunto claro de pruebas ilustrativas y sus resultados junto con un conjunto de instrucciones concisas que le ayudarán a elegir la tecnología más adecuada para sus necesidades.

En resumen, nuestros objetivos para este documento son:

1. Para investigar cuáles son las diferencias de rendimiento relativas entre las tres tecnologías para la mayoría de las aplicaciones empresariales
2. Para corregir algunas suposiciones con respecto a las sanciones de rendimiento percibidos de una tecnología sobre otra
3. Para ayudar a guiar sus decisiones sobre dónde, cuándo y cómo usar cada tecnología de forma más adecuada
4. Para proporcionar una aplicación de prueba para que pueda ejecutar estas pruebas en sus propias máquinas y en sus propios entornos. Le recomendamos encarecidamente que compile y ejecute este entorno de prueba e investigue y analice las características de rendimiento de estas tecnologías. De esta manera podrá comprender plenamente los muchos factores que afectan al rendimiento de los sistemas distribuidos.

Esto no es una prueba comparativa

Las pruebas presentadas en estas notas del producto están diseñadas explícitamente para proporcionar resultados comparativos coherentes entre las tecnologías específicas sometidas a prueba. Estas pruebas no están diseñadas para medir el máximo rendimiento posible absoluto para cada tecnología bajo carga.

La aplicación del controlador de prueba (cliente) es de un solo subproceso y realiza llamadas sincrónicas serie tan rápidamente como responde el servicio llamado. Con este diseño, el cuello de botella no siempre es el uso de cpu del servidor.

Varios clientes, o un cliente multiproceso, pueden dar lugar a que el servidor procese más llamadas por segundo. En el caso de las pruebas de aplicación de servidor más intensivas de CPU, varios clientes no cambian significativamente el rendimiento absoluto o relativo de las tecnologías que se están probando.

Para las pruebas más ligeras, se puede lograr un rendimiento de servidor agregado (2X) significativamente mayor mediante el uso de varios clientes. Varios clientes también pueden cambiar un poco el rendimiento relativo de las diversas tecnologías.

Si un único cliente o varios clientes es más realista depende de dónde y cómo se implementa un servicio web. Las conclusiones del documento no se ven afectadas por la decisión de medir con un solo cliente.

Pruebas

En las siguientes pruebas de rendimiento, se exploran las líneas base sintéticas y los escenarios reales. Las preguntas comunes que hemos establecido para examinar son las siguientes:

1. ¿Es .NET Remoting más rápido que ASMX?
2. ¿ES más lento que la comunicación remota?
3. ¿ASMX es demasiado lento para escenarios reales?

• Para examinar estas notificaciones, hemos realizado varias pruebas. Las pruebas principales examinan el rendimiento de realizar llamadas contra acciones que aceptan una solicitud grande y realizan un trabajo significativo o se solicitan para realizar un trabajo significativo y devolver conjuntos de resultados pequeños o grandes. El objetivo de estas pruebas es ilustrar el rendimiento de escenarios empresariales típicos que es probable que experimente al crear los sistemas.

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

• Enterprise Services (mediante la activación Just-In-Time)
  • Sin autenticación
  • Autenticación de nivel de llamada y comprobaciones de acceso a roles aplicadas
• servicios web de ASP.NET
  • Sin autenticación
  • Autenticación mediante nombre de usuario y contraseña
  • Autenticación integrada
• .NET Remoting
  • TCP/Binary, no seguro
  • HTTP/Binary, no seguro
  • HTTP/SOAP, no seguro
  • HTTP/SOAP en IIS, no seguro
  • HTTP/Binary en IIS, no seguro
  • HTTP/SOAP en IIS, autenticación básica HTTP
  • HTTP/Binary en IIS, autenticación básica HTTP
  • HTTP/SOAP en IIS, autenticación integrada
  • HTTP/Binary en IIS, autenticación integrada

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

Resultado

Prueba 1: Creación y almacenamiento de pedidos

Esta primera prueba se diseñó para simular las características de rendimiento que exhibe cada tecnología en el caso más óptimo, donde la acción a la que se llama realiza un trabajo significativo. Para realizar un trabajo significativo, la acción que se llama almacena pedidos en una base de datos que implica escribir registros en dos tablas dentro de 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 invocación del método y se serializa en la conexión mediante las distintas tecnologías que se están probando.

La implementación del lado 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();
   }
}

Una vez completada la ejecución de pruebas, la lógica del lado servidor usa una segunda transacción para eliminar los registros insertados, lo que proporciona un "campo de juego de nivel" independientemente del número de veces que se ejecute esta prueba.

Figura 1. Pasar una "orden" entre máquinas con una implementación real del lado servidor

Al examinar los resultados de la prueba en la figura 1, tenga en cuenta que solo hay una diferencia del 14 % entre ES @73 CPS y ASP.NET servicios web @63 CPS, y que la diferencia máxima entre los protocolos más rápido y más lento es del 45 %. Esto muestra claramente que el beneficio de cualquier transporte determinado sobre otro disminuye a medida que la cantidad de trabajo realizado crece en proporción al tiempo que se tarda en transportar datos.

También hemos creado una prueba ADO.NET DataSet coincidente, creando conjuntos de datos con tipo que contienen DataTables definidos como en la figura 2.

Ilustración 2. Este conjunto de datos representa un pedido de compra.

Este DataSet se usa con un sqlDataAdapter generado, incluido SqlCommands, similar a los que se muestran en los fragmentos de código anteriores.

Cuando el pedido se pasa desde el autor de la llamada al servidor como dataSet y, a continuación, se almacenan los resultados que se muestran en la figura 3.

Figura 3. Almacenar un pedido de compra como DataSet

Observe el impacto significativo en el rendimiento del uso de DataSets (alrededor de un 50 % de ralentización), junto con el hecho de que la diferencia entre los protocolos disminuye aún más. También es importante tener en cuenta que los resultados más lentos de pasar objetos de datos superan el mejor rendimiento al pasar ADO.NET DataSets.

Esto muestra claramente que pasar ADO.NET DataSets entre niveles de un sistema conlleva una penalización significativa del rendimiento.

Prueba 2: Recuperación de datos del producto Northwind

El propósito de esta prueba es ilustrar las características de rendimiento de cada tecnología cuando se devuelve una cantidad relativamente grande de datos de un servicio que no realiza un trabajo significativo.

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

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

En la primera prueba, definimos una [Serializable] clase 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 del lado servidor, se abre una conexión de base de datos a SQL Server, se ejecuta una consulta en la base de datos y, mediante una ADO.NET SqlDataReader, se rellena una arrayList que contiene 77 instancias de producto de esta clase. A continuación, arraylist se devolvió al autor de la llamada.

Los resultados se muestran en la figura 4.

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

Estos resultados muestran que Enterprise Services (a través de DCOM) y la comunicación remota binaria basada en TCP proporcionan niveles iguales de rendimiento para las llamadas no seguros. Los resultados también muestran que ASP.NET servicios web proporciona aproximadamente el 62 % del rendimiento de Enterprise Services y que los protocolos más lentos solo permiten el 17 % del número de llamadas por segundo en comparación con la más rápida.

En esta y todas las siguientes pruebas, es claro por qué general no se recomienda usar soapFormatter de .NET Remoting para compilar servicios SOAP: la pila de servicios web de ASP.NET es aproximadamente tres veces tan rápido.

En el segundo enfoque de esta prueba, hemos implementado un método que devuelve los datos solicitados en un objeto DataSet de ADO.NET que se basa directamente en el diseño de tabla subyacente y rellena la DataTable de DataSet mediante sqlDataAdapter. La definición de tabla se muestra en la figura 5.

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

En la figura 6 se muestran los resultados:

Figura 6. Recuperación del catálogo de productos northwind como dataset

Es claro que los resultados de esta prueba que devuelven DataSets del servicio al autor de la llamada reducen significativamente el rendimiento, alrededor del 75 % para los transportes binarios. Tenga en cuenta también que el rendimiento de los cuatro protocolos más rápidos es completamente idéntico, lo que significa que las cuatro tecnologías se limitaron mediante la serialización, la des serialización y el transporte del DataSet. Además, tenga en cuenta que la gama de rendimiento entre la más rápida (ASMX @ 39 cps) y la seguridad integrada más lenta (HTTP/SOAP (IIS) Integrada de seguridad @ 25 cps) están separadas por solo 14 cps, un solo 30 % de caída.

Esto ilustra que, aunque resulta conveniente usar DataSets para pasar información entre los niveles de las aplicaciones, hay un impacto significativo en el rendimiento al hacerlo. Volveremos a este tema más adelante.

También es importante señalar que es más rápido recorrer en iteración un dataSet de ADO.NET y construir una colección de objetos de datos y serializar esta colección que devolver el dataSet ADO.NET al autor de la llamada. Si se trata de un sistema real, implementado para pasar DataSets entre el servidor y el autor de la llamada, podríamos cuadruplicar el rendimiento de esta parte del sistema con solo una pequeña cantidad de trabajo.

Prueba 3: Recuperación de la información del cliente

En la siguiente prueba, queríamos examinar las características de rendimiento relativas 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 SQL Server ejemplo "Northwind".

Hemos creado la siguiente clase Customer [Serializable] para devolver los datos recuperados al cliente desde el 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 se muestra una parte de nuestra implementación del lado servidor que usa sqlDataReader para rellenar una nueva 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 se muestran en la figura 7.

Ilustración 7. Recuperar los datos de un cliente como un objeto

Estos resultados resaltan de forma más destacada las diferencias de rendimiento entre cada una de las tecnologías subyacentes. Estas diferenciales son tan visibles en esta prueba porque el trabajo que se realiza para recuperar y devolver un único registro es un porcentaje mucho menor del costo total de llamadas y, por tanto, el costo del transporte desempeña un papel más significativo. Por lo tanto, dado que SOAP/HTTP tiene un costo mayor de transporte que binary/DCOM, los transportes SOAP muestran niveles de rendimiento mucho más bajos que los mecanismos binarios.

A continuación, probamos la misma operación que devuelve un DataSet con tipo, que se muestra en la figura 8.

Figura 8. DataSet con tipo para acceder a la información de un cliente

Este conjunto de datos se rellena mediante una implementación del lado 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 dentro de nuestro marco de pruebas, recibimos los resultados que se muestran en la figura 9.

Figura 9. Recuperar los datos de un cliente como dataset

De forma similar a las pruebas anteriores, es evidente que el intercambio de ADO.NET Conjuntos de datos afecta negativamente al rendimiento y la diferencia en el rendimiento de todas las tecnologías se vuelve menor que cuando se devuelven objetos serializados que ilustran que ADO.NET DataSets están limitando el rendimiento.

Rendimiento de .NET Framework 2.0

En el momento de escribir este documento, Microsoft está trabajando para entregar .NET Framework 2.0 (anteriormente denominado "Whidbey") que incluye un gran número de mejoras, mejoras y nuevas funcionalidades, entre las que se incluyen:

• Compatibilidad total con máquinas basadas en x64 e IA64
• Compatibilidad con transacciones nuevas a través de System.Transactions
• Muchas mejoras para System.Net, incluido el reconocimiento de conectividad y la compatibilidad con servidores proxy
• Mejoras significativas para Windows Forms y Web Forms
• Infraestructura de implementación automática de aplicaciones "ClickOnce"

Además de las características nuevas y mejoradas incluidas en .NET Framework 2.0, se ha realizado una gran cantidad de trabajo para aumentar significativamente el rendimiento y mejorar el uso de memoria en muchas áreas, como BCL, serialización XML, rendimiento de red, ADO.NET, ASP.NET, etc.

Los primeros ejemplos de estas mejoras de rendimiento y rendimiento se pueden ver en las notas del producto siguientes:

• Comparación del rendimiento XML

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

• Comparación del rendimiento del servicio web

  Resultados de pruebas comparativas de WS Test 1.1 para .NET Framework 2.0, .NET 1.1, Sun JWSDP 1.5 e IBM WebSphere 6.0

En los próximos meses se publicarán más notas del producto de análisis y comparación de rendimiento, ya que .NET Framework 2.0 continúa su trayectoria hacia RTM (lanzamiento a fabricación). Para mantenerse al día con estas notas del producto, visite los siguientes recursos en línea:

• Centro para desarrolladores de .NET Framework
• Informes y pruebas competitivos: Comparación de .NET con J2EE

Conclusiones

Los resultados de las pruebas reales anteriores se muestran en la tabla 1.

Tabla 1. Resumen de resultados

Llamadas por segundo (redondeado)	Enterprise Services	servicios web de ASP.NET	.NET Remoting TCP Binary
Prueba 1: Almacenamiento de pedidos a) Datos serializados b) DataSet	73 35	63 34	72 34
Prueba 2: Recuperación de productos a) Datos serializados b) DataSet	147 39	93 39	149 39
Prueba 3: Recuperación del cliente a) Datos serializados b) DataSet	618 90	289 83	682 91

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

Nuestras observaciones de las tecnologías que se están probando se describen con más detalle en la sección siguiente, pero se pueden resumir aquí:

• Aunque ASMX no es absolutamente la tecnología más rápida que se envía actualmente, su rendimiento es más que adecuado para la mayoría de los escenarios empresariales. Junto con los hechos que los servicios ASMX son fáciles de escalar horizontalmente y proporcionar una gran cantidad de otras ventajas, como la interoperabilidad y la compatibilidad futura, ASMX debe ser su elección principal para crear servicios hoy en día.
• Si el rendimiento absoluto es de la máxima preocupación, los componentes de Enterprise Services deben usarse para crear las partes más críticas del rendimiento del sistema. COM+ ha realizado mejor en general y es un entorno de hospedaje seguro, seguro y confiable para componentes distribuidos. ES/COM+ también se integrará bien con los servicios indigo y será relativamente sencillo convertir componentes es en servicios indigo.
• Aunque .NET Remoting funciona muy bien cuando se usa la serialización binaria a través de TCP, su rendimiento disminuye cuando los componentes de comunicación remota se hospedan en IIS o al enviar y recibir mensajes SOAP. Junto con el hecho de que los componentes de .NET Remoting no interoperarán con ningún otro punto de conexión que no sea .NET Remoting, le instamos a considerar ASMX o ES antes de la comunicación remota siempre que sea posible.

Una observación clave para extraer de estos resultados es que si la cantidad de trabajo realizado en el servidor no es un porcentaje significativo de la duración total de cada llamada, el tiempo de transporte tendrá por lo tanto una parte significativa del tiempo de llamada. Si pasa de un transporte "rápido" (como DCOM bajo COM+) a un transporte más "costoso" (como SOAP/HTTP en ASMX), puede experimentar un impacto significativo en el rendimiento. Por lo tanto, nuestra guía para realizar tanto trabajo como sea posible en el servidor para cada llamada de método y para evitar realizar recorridos de red innecesarios se muestra claramente.

Las ventajas de rendimiento de estas tecnologías sobre otras reducen a medida que aumenta la cantidad de trabajo que realiza el servicio llamado. Esta observación se ha indicado en muchos artículos, incluido el rendimiento de los servicios empresariales de .NET.

También es evidente que las diferencias de rendimiento entre estas tecnologías son más pequeñas que las diferencias entre las decisiones específicas de la aplicación, como el uso de conjuntos de datos o estructuras serializadas.

Aunque nos hemos centrado enormemente en los números de rendimiento de este documento, el rendimiento no es el único factor que debe tener en cuenta al planear los proyectos de desarrollo. Otros factores como la seguridad, la escalabilidad, la administración, la productividad del desarrollador, la interoperabilidad y la dirección futura de las tecnologías distribuidas de Microsoft entran en juego. Desarrollar servicios distribuidos En la actualidad se presentan las instrucciones prescriptivas sobre cómo elegir mejor cuándo y dónde usar cada tecnología y cuál es el futuro.

Recomendaciones

En función de los resultados de estas pruebas, y de acuerdo con nuestra futura dirección tecnológica y procedimientos recomendados, podrá crear sistemas que no son tan propensos a problemas de rendimiento mediante la adhesión a las siguientes recomendaciones:

Usar ASMX siempre que sea posible

Para proporcionar el alcance más amplio de los servicios, considere la posibilidad de publicar los servicios con ASMX siempre que sea posible. Esto permitirá que cualquier sistema que pueda hablar con SOAP a través de HTTP llame a su servicio, independientemente de la plataforma, el dispositivo o el lenguaje en el que se pueda ejecutar el sistema o implementarse. Como puede ver en los resultados anteriores, ASMX realiza de forma admirable en muchos escenarios. Incluso en nuestra máquina de un solo procesador a la que llama una aplicación de un solo subproceso, ASMX es capaz de procesar algunas 63 operaciones pesadas por segundo, solo 10 llamadas por segundo menos que el componente ES equivalente. En un entorno de producción, puede esperar mucho más rendimiento de un solo cuadro que hospeda servicios ASMX, por lo que el rendimiento de ASMX no debe bloquear la adopción de esta tecnología importante.

Los servicios web muestran otros rasgos y características útiles, entre los que se incluyen (pero no limitados a):

• Escalabilidad: es muy fácil escalar horizontalmente un servicio web mediante la tecnología de equilibrio de carga, como el equilibrio de carga de red de Windows, o dispositivos de hardware de proveedores como Cisco y F5. Más información sobre este tema a seguir.
• Disponibilidad: los servicios web ASMX se pueden configurar para que sean de alta disponibilidad mediante una combinación de tecnologías como el equilibrio de carga combinado con las eficaces funcionalidades de la infraestructura de IIS6 integrada en Windows 2003 Server (como el reciclaje automático y el reinicio de los servicios con errores).
• Interoperabilidad: los servicios web se encuentran en el núcleo del movimiento para estandarizar protocolos de comunicaciones interoperables seguros, confiables y transacciones, lo que permite que los sistemas heterogéneos dispares se comuniquen libremente.
• Productividad: la creación de servicios web ASMX es muy fácil para la mayoría de los desarrolladores a través del uso prudente de algunos atributos y siguiendo algunas recomendaciones.

Uso de ASMX para servicios web

Hay muchas razones por las que ASMX es una excelente plataforma para compilar e implementar servicios como se describe en la guía prescriptiva, y como se puede ver en los resultados de este documento, ASMX suele superar la comunicación remota al hablar con SOAP.

También es importante tener en cuenta que, aunque .NET Remoting es capaz de admitir SOAP/HTTP (a través de soapFormatter y HttpChannel), se recomienda usar la comunicación remota para exponer servicios web. .NET Remoting SoapFormatter usa RPC-Encoding, que ya no es la forma estándar de codificar SOAP (document-literal es el mecanismo de codificación estándar futuro utilizado por la mayoría de las tecnologías y plataformas de los proveedores); por lo tanto, la interoperabilidad con los servicios de comunicación remota será muy limitada.

Elección de servicios web para escalabilidad

Una cosa no ilustrada anteriormente, pero muy relevante para esta discusión, es que los servicios web hablan principalmente sobre HTTP, una tecnología de comunicaciones sin estado que es fácil de equilibrar la carga. Esto significa que también es posible equilibrar la carga de componentes de comunicación remota sin estado mediante TCP o HTTP (es decir, hospedado en IIS), aunque esto puede resultar complejo y problemático si se requiere el estado de sesión.

Para equilibrar la carga de los componentes ES/COM+, debe usar equilibrio de carga de componentes (CLB), una característica de Application Center 2000. Por desgracia, AppCenter 2000 entra en soporte extendido en julio de 2006 y el soporte finaliza en 2011. Por lo tanto, para evitar tener que volver a diseñar sus sistemas antes de que 2011 ya no dependa de CLB, es muy recomendable evitar esta tecnología para el nuevo desarrollo y, en su lugar, migrar a otras estrategias tan pronto como sea posible. Una buena estrategia de migración es hacer frente a los componentes actuales de COM+ con servicios web ASMX, que simplemente pasan llamadas directamente al componente COM+ y para equilibrar la carga de los servicios web como se ha descrito anteriormente.

Usar Enterprise Services solo dentro de los servicios

.NET Enterprise Services es una capa de .NET Framework que proporciona acceso a los servicios enriquecidos ofrecidos por COM+. Si necesita cualquiera de los servicios COM+ enriquecidos, como transacciones distribuidas que abarcan varios objetos o servicios, seguridad específica, JITA y agrupación de objetos, debe elegir Enterprise Services. Enterprise Services y COM+ son tecnologías bien probadas y altamente optimizadas que proporcionan llamadas cruzadas y entre equipos extremadamente rápidas y de baja latencia.

Sin embargo, se recomienda encarecidamente que no exponga ampliamente los componentes de Enterprise Services y que use esta tecnología solo dentro de su límite de servicio. Si desea proporcionar acceso a su servicio, le instamos a exponer las funcionalidades de su servicio a través de servicios web mediante ASMX. Si tiene una base de código ES/COM+ establecida, le sugerimos que fronting sus servicios COM+ con los servicios web ASMX siempre que sea posible.

Considere la posibilidad de crear una infraestructura hospedada a través de la creación propia

Como se puede ver anteriormente, ASP.NET ofrece servicios web de gran rendimiento que son altamente interoperables y también se benefician de las excelentes instalaciones de hospedaje proporcionadas por IIS, especialmente IIS6 en el servidor de Windows 2003.

COM+ proporciona el rendimiento de componentes más rápido en la plataforma Microsoft junto con ser un entorno de hospedaje probado, de confianza, seguro, seguro y confiable para los componentes de Enterprise Services y COM+. También proporciona compatibilidad con transacciones distribuidas, seguridad (autenticación y cifrado), confiabilidad, disponibilidad, servicios de administración y es una excelente opción para hospedar sistemas complejos basados en componentes dentro del servicio.

Aunque .NET Remoting mediante serialización binaria a través de TCP también proporciona un rendimiento excelente, no proporciona ningún entorno de hospedaje, seguridad, confiabilidad, disponibilidad o características de administración "lista para usar". Para hospedar componentes de comunicación remota que usan TCP, debe escribir su propia aplicación de hospedaje (segura, escalable y confiable) y esto no es una tarea trivial. Si desea usar la comunicación remota a través de HTTP, opcionalmente puede usar IIS como host, pero como puede ver, hospedar el componente comunicación remota en IIS y hablar SOAP/HTTP afecta considerablemente al rendimiento de la comunicación remota, a menudo hasta el punto en que ASMX funciona mejor.

Por lo tanto, le instamos a considerar la posibilidad de ofrecer sus servicios en ASMX hospedados en componentes de IIS o Enterprise Services dentro de COM+, en lugar de usar la comunicación remota, siempre que sea posible.

Evitar pasar conjuntos de datos entre servicios

En nuestras pruebas, la elección de la forma en que los servicios y los autores de llamadas intercambian datos ,como Conjuntos de datos o estructuras serializadas, dio lugar a un impacto en el rendimiento mucho mayor que elegir cualquier tecnología de sistemas distribuidos en particular sobre otra.

Desde una perspectiva de rendimiento, le instamos encarecidamente a limitar el uso de DataSets como mecanismo de transferencia de datos a las partes de la aplicación donde realmente son necesarias y que opte por [Serializable] estructuras siempre que sea posible.

ADO.NET DataSets proporcionan una excelente manera de recuperar, manipular, ordenar y dar forma a los datos, almacenarlos localmente para su uso sin conexión y sincronizar los cambios en una base de datos central. Si se trata de un requisito de la aplicación, por supuesto, es una opción válida para tomar. En .NET Framework 1.x, los valores de DataSet siempre se serializan en XML (aunque indique que quiere que se serialicen como binarios o utilícelos con ES o Comunicación remota), y también contienen el XSD que describe los datos. Esto, por supuesto, afecta al rendimiento.

Además, recuerde que los Conjuntos de datos son . La tecnología específica de NET y limitará significativamente la interoperabilidad, ya que otras plataformas no necesariamente podrán serializar y analizar los datos que contienen conjuntos de datos serializados.

Puede obtener mejoras de rendimiento considerables mediante el intercambio de estructuras de datos serializadas. El formato en tiempo de ejecución integrado y el marco de serialización XML facilitan la tarea, como se muestra en las pruebas anteriores.

Uso compartido de conexiones autenticadas

Todas las pruebas que usan 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 ASP.NET Clientes y .NET Remoting. Esta configuración permite que el cliente y el servidor vuelvan a usar una conexión ntLM autenticada existente.

Puede ver los resultados de rendimiento cuando establecemos esta opción en la figura 10 durante las pruebas presentadas originalmente en la figura 1 (almacenando un pedido de compra como objetos). Tenga en cuenta que esta configuración solo tiene un efecto si usa Internet Information Server (IIS) como servidor y si exige "Windows En seguridad" en la configuración del directorio virtual.

La columna Web Q&A: Almacenamiento en caché de transformaciones, uso compartido de conexiones y más de MSDN Magazine de septiembre de 2004 analiza estos inconvenientes.

Figura 10. El impacto de UnsafeAuthenticatedConnectionSharing

Puede usar la seguridad integrada de Windows junto con esta configuración desde ASP.NET servicios web como este:

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

Y con .NET Remoting de la siguiente manera:

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

Apéndice A: Línea base sintética- Prueba de método vacío

Esta prueba "líneas base" las diferencias de rendimiento entre las tecnologías subyacentes que se examinan. Estas pruebas realizan llamadas a acciones que no aceptan parámetros, no realizan ningún trabajo y no devuelven resultados. La implementación del lado servidor es tan sencilla como:

public void TransferEmpty()
{
   // do nothing
}

Nota Es importante recordar que estas cifras de línea base sintéticas se presentan exclusivamente 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. Llamar a un método sin parámetros entre procesos (línea base sintética)

Los resultados de nuestras pruebas en la figura 11 coincidieron muy estrechamente con las suposiciones comunes: ES proporciona con mucho el mejor rendimiento debido a su dependencia de COM+ y DCOM y la infraestructura de comunicaciones en caja LPC (llamada a procedimiento ligero) de alto rendimiento. Los protocolos de conexión de .NET Remoting vienen en segundo lugar. ASP.NET servicios web viene tercero, pero sigue siendo más rápido que los componentes de .NET Remoting hospedados en IIS.

Como segundo paso, ejecutamos esta prueba entre máquinas. Hemos redirigido el ASP.NET generado estableciendo su propiedad "Url", exportó un proxy de aplicación para los componentes com+/Enterprise Services y usó Activator.GetObject() para la parte de comunicación remota de .NET de esta prueba. Los resultados han resultado estar muy alineados con las pruebas anteriores, pero con un número ligeramente menor de llamadas por segundo debido a los recorridos de red implicados:

Ilustración 12. Llamar a un método vacío sin parámetros entre máquinas (línea base sintética)

Tenga en cuenta que el recorrido de red entre máquinas ha limitado esencialmente los transportes más rápidos (ES y Remoting Binary/TCP), mientras que apenas afecta a los transportes más lentos. Esto ilustra claramente la eficacia de los mecanismos de comunicación entre procesos de COM+ en particular en comparación con las tecnologías creadas principalmente para atender el tráfico de red (es decir, ASMX de IIS & ).

Es importante recordar, como se mencionó anteriormente, que esta prueba es muy artificial y solo ilustra las capacidades de los transportes.

Apéndice B: Resultados detallados de pruebas

Almacenar pedido como objeto

Probar	Promedio de llamadas/segundo	Desviación std.
Enterprise Services	73	0.39
Enterprise Services (autenticación)	73	0.34
Comunicación remota de TCP/Binary	72	2.71
Comunicación remota http/binario	68	0,86
Comunicación remota HTTP/Binary (IIS)	66	0,31
servicios web de ASP.NET	63	2.71
Contraseña http/binaria (IIS) de comunicación remota	63	0.39
Comunicación remota tcp/SOAP	56	1.97
Comunicación remota HTTP/SOAP	53	0,57
Comunicación remota http/binario (IIS) integrado	51	0,28
Comunicación remota HTTP/SOAP (IIS)	50	0.16
servicios web de ASP.NET: integrado	50	0,30
Contraseña http/SOAP (IIS) de comunicación remota	49	0,29
Comunicación remota HTTP/SOAP (IIS) integrado	40	0,84

Almacenar pedido como DataSet

Probar	Promedio de llamadas/segundo	Desviación std.
Enterprise Services	35	0,54
Enterprise Services (autenticación)	35	0,51
servicios web de ASP.NET	34	0,43
Comunicación remota de TCP/Binary	34	0,85
Comunicación remota http/binario	32	0.77
Comunicación remota HTTP/Binary (IIS)	32	1.10
Comunicación remota tcp/SOAP	32	0.77
Contraseña http/binaria (IIS) de comunicación remota	31	1.47
Comunicación remota HTTP/SOAP	30	0,68
Comunicación remota HTTP/SOAP (IIS)	30	0,48
Contraseña http/SOAP (IIS) de comunicación remota	30	0,46
servicios web de ASP.NET: integrado	29	0,37
Comunicación remota http/binario (IIS) integrado	28	0,37
Comunicación remota http/SOAP (IIS) integrada	26	0,31

Cargar productos como objetos

Probar	Promedio de llamadas/segundo	Desviación std.
Comunicación remota tcp/binario	149	3.05
Enterprise Services	147	2.29
Enterprise Services (autenticación)	146	2.49
Comunicación remota http/binario	118	2,13
Comunicación remota http/binario (IIS)	114	0.63
Contraseña http/binaria de comunicación remota (IIS)	106	1.19
servicios web de ASP.NET	93	1.04
Comunicación remota http/binario (IIS) integrado	76	0.81
servicios web de ASP.NET: integrado	67	0.35
Comunicación remota tcp/SOAP	33	0.34
Comunicación remota http/SOAP	30	0,32
Comunicación remota de HTTP/SOAP (IIS)	30	0,25
Contraseña http/SOAP (IIS) remota	29	0.16
Comunicación remota http/SOAP (IIS) integrada	26	0.14

Cargar productos como DataSet

Probar	Promedio de llamadas/segundo	Desviación std.
servicios web de ASP.NET	39	0,12
Enterprise Services	39	0,26
Enterprise Services (autenticación)	39	0,21
Comunicación remota tcp/binario	39	1.16
Comunicación remota http/binario (IIS)	36	0,24
Comunicación remota http/binario	35	1.10
Contraseña http/binaria de comunicación remota (IIS)	35	0,17
servicios web de ASP.NET: integrado	33	0,09
Comunicación remota http/binario (IIS) integrado	31	0,21
Comunicación remota tcp/SOAP	30	1.27
Comunicación remota de HTTP/SOAP (IIS)	29	0,12
Comunicación remota http/SOAP	28	1.07
Contraseña http/SOAP (IIS) remota	28	0,06
Comunicación remota HTTP/SOAP (IIS) integrado	25	0,08

Cargar cliente como objeto

Probar	Promedio de llamadas/segundo	Desviación std.
Comunicación remota de TCP/Binary	682	12.32
Enterprise Services	618	13.78
Enterprise Services (autenticación)	616	7.76
Comunicación remota http/binario	406	7.84
Comunicación remota tcp/SOAP	359	11.62
Comunicación remota HTTP/Binary (IIS)	324	4.26
servicios web de ASP.NET	289	2.68
Comunicación remota HTTP/SOAP	267	6,18
Contraseña http/binaria (IIS) de comunicación remota	261	2,39
Comunicación remota HTTP/SOAP (IIS)	214	2,84
Contraseña http/SOAP (IIS) de comunicación remota	186	0.81
Comunicación remota http/binario (IIS) integrado	134	0,95
servicios web de ASP.NET: integrado	130	0,67
Comunicación remota HTTP/SOAP (IIS) integrado	112	0,55

Cargar cliente como DataSet

Probar	Promedio de llamadas/segundo	Desviación std.
Comunicación remota de TCP/Binary	91	2.69
Enterprise Services	90	0,30
Enterprise Services (autenticación)	90	0,26
servicios web de ASP.NET	83	0,24
Comunicación remota http/binario	80	0,67
Comunicación remota tcp/SOAP	78	1.04
Comunicación remota HTTP/Binary (IIS)	78	0.22
Contraseña http/binaria (IIS) de comunicación remota	75	0,26
Comunicación remota HTTP/SOAP	71	0,92
Comunicación remota HTTP/SOAP (IIS)	67	0.34
Contraseña http/SOAP (IIS) de comunicación remota	64	0,20
servicios web de ASP.NET: integrado	62	0.14
Comunicación remota http/binario (IIS) integrado	59	0,15
Comunicación remota HTTP/SOAP (IIS) integrado	52	0,13

Mensaje vacío, cross-process

Probar	Promedio de llamadas/segundo	Desviación std.
Enterprise Services	14687	52.66
Enterprise Services (autenticación)	12293	31.71
Comunicación remota de TCP/Binary	3538	38.87
Comunicación remota http/binario	1069	8.05
Comunicación remota tcp/SOAP	1075	11.87
Comunicación remota HTTP/SOAP	612	7,88
Comunicación remota HTTP/Binary (IIS)	589	1,83
servicios web de ASP.NET	517	1.44
Comunicación remota http/binario (IIS) integrado	451	1.19
Contraseña http/binaria (IIS) de comunicación remota	421	0.90
Comunicación remota HTTP/SOAP (IIS)	406	1,76
servicios web de ASP.NET: integrado	403	0,76
Comunicación remota HTTP/SOAP (IIS) integrado	336	0,57
Contraseña http/SOAP (IIS) de comunicación remota	321	0,37

Mensaje vacío. Entre máquinas

Probar	Promedio de llamadas/segundo	Desviación std.
Enterprise Services (autenticación)	3068	25,35
Enterprise Services	3048	38.24
Comunicación remota de TCP/Binary	2609	77.28
Comunicación remota tcp/SOAP	760	31.65
Comunicación remota http/binario	704	8.00
Comunicación remota HTTP/Binary (IIS)	479	2.60
Comunicación remota HTTP/SOAP	413	10.63
servicios web de ASP.NET	399	2.00
Contraseña http/binaria (IIS) de comunicación remota	351	1.98
Comunicación remota HTTP/SOAP (IIS)	309	1.38
Contraseña http/SOAP (IIS) de comunicación remota	252	1,25
Comunicación remota http/binario (IIS) integrado	156	0,52
servicios web de ASP.NET: integrado	150	0,57
Comunicación remota HTTP/SOAP (IIS) integrado	133	0,28

Apéndice C: Probar notas de la aplicación

Ejecución de la aplicación de prueba

Puede descargar la aplicación de prueba en la ubicación especificada al principio de este artículo. Para realizar estas pruebas en su propio hardware, necesitará al menos dos máquinas: un cliente y un servidor. Además, deberá tener acceso a una instalación de SQL Server que incluya la base de datos de ejemplo Northwind. Encontrará una guía paso a paso sobre cómo implementar, configurar y ejecutar este conjunto de pruebas en el archivo README.TXT que forma parte del archivo ZIP que contiene el código fuente.

Factoid interesante: la aplicación de prueba es independiente de la tecnología.

Verá en la aplicación de prueba que es posible crear aplicaciones independientes del 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 lado cliente (un proxy de servicio web o el correspondiente TransparentProxy para ES y .NET Remoting) que implementa una interfaz determinada. Al llamar a este método, puede especificar qué protocolo de transporte se debe usar, qué configuración de seguridad, formateadores, etc. La aplicación restante no se preocupa por el protocolo subyacente. Esto le permite crear una aplicación independiente del protocolo, lo que le permite elegir los protocolos adecuados según el entorno de la aplicación.

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

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

Entorno de aplicación

• Cliente: aplicación de consola de un solo subproceso, escrita en C#, compilada con Visual Studio.NET 2003 en modo de versión.
• ASP.NET servicio web que se ejecuta en IIS 6.0 en Windows Server 2003
• Componentes de Enterprise Services en distintas configuraciones (activación de biblioteca y activación del servidor, sin autenticación y autenticación de nivel de llamada) que se ejecutan en COM+ 1.5 en Windows Server 2003
• Un servidor independiente de .NET Remoting como una aplicación de consola de C#, escrita en C#, creada con Visual Studio .NET 2003 en modo de versión

Entorno de infraestructura

Cliente:

• CPU: Intel P4 de 2,4 GHz
• Memoria: 768 MB
• O/S: Windows Server 2003 Standard Edition (con todas las revisiones a partir de junio de 2004)
• .NET Framework 1.1 SP1

Servidor de aplicaciones:

• CPU: Intel P4 de 2,8 GHz
• Memoria: 1024 MB
• Sistema operativo: Windows Server 2003 Standard Edition
• .NET Framework 1.1 SP1

Servidor de base de datos:

• CPU: Intel P4 Prescott de 2,8 GHz, w/ HT, FSB de 800 MHz
• Memoria: 1024 MB
• Sistema operativo: 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