Leistung ASP.NET Webdienste, Enterprise Services und .NET Remoting

 

Ingo Rammer
thinktecture.

Richard Turner
Program Manager (Programm-Manager)
Microsoft Distributed Systems Group

August 2005

Zusammenfassung: Vergleichen und kontrastieren Sie die Leistungseigenschaften von realen ASP.NET Webdiensten, .NET Enterprise Services-Komponenten und .NET Remoting-Komponenten, und erhalten Sie Empfehlungen zur optimalen Verwendung dieser Technologien. (34 gedruckte Seiten)

Laden Sie das zugehörige Codebeispiel ASMXvsEnterpriseServicesvsRemotingPerformanceTests.msiherunter.

Inhalte

Einführung
Ziele
   Dies ist kein Benchmark
   Die Tests
Das Ergebnis
   Test 1: Erstellen und Speichern von Aufträgen
   Test 2: Abrufen der Produktdaten von Northwind
   Test 3: Abrufen von Kundeninformationen
.NET Framework 2.0 Leistung
Zusammenfassung
   Empfehlungen
Anhang A: Synthetische Baseline – Test der leeren Methode
Anhang B – Detaillierte Testergebnisse
   Bestellung als Objekt speichern
   Bestellung als DataSet speichern
   Produkte als Objekte laden
   Laden von Produkten als DataSet
   Kunde als Objekt laden
   Kunden als DataSet laden
   Leere Nachricht, Prozessübergreifend
   Leere Nachricht. Computerübergreifend
Anhang C: Testanwendungshinweise
   Ausführen der Testanwendung
   Interessant: Die Test-App ist technologieunabhängig!
Anhang D: Software- und Hardwareeinrichtung
   Anwendungsumgebung
   Infrastrukturumgebung

Einführung

Während die absolute Leistung für mehrere Technologiebereiche (Geräte, Hardwarecontroller, Lebens- und Gesundheitsdienstleistungen, bestimmte Finanzsysteme) von größter Bedeutung ist, gehören diese in der Regel zur Minderheit. Die hauptzieligen Ziele der meisten Geschäftsanwendungen sind "Korrektheit", "Time to Delivery" und die Notwendigkeit, so schnell wie erforderlich zu sein, aber nicht mehr. Die Kosten und der Aufwand von Technischen Anwendungen, die absolut maximale Leistung bieten, können enorm sein; Die für Spitzenleistungen erforderliche zeit- und geschickliche Zeit ist für viele Geschäftssysteme häufig unnötig. Obwohl die absolute Höchstleistung oft übertrieben ist, ist die Sicherstellung einer guten Gesamtleistung des Systems immer noch ein Ziel für die meisten Unternehmen, die ihre Rendite maximieren möchten.

In diesem Whitepaper bieten wir eine vergleichende Analyse der relativen Leistungsniveaus realer Komponenten/Dienste, die in jeder der drei verteilten Komponenten/Diensttechnologien gehostet werden, die in .NET verfügbar sind:

• In COM+ gehostete .NET Enterprise Services (ES)
• ASP.NET Webdienste (ASMX), die in IIS gehostet werden
• .NET Remoting, das in IIS und benutzerdefinierten Hosts gehostet wird

(Hinweis Die Leistung von System.Messaging- und MSMQ-COM-APIs wird im Artikel System.Messaging-Leistung behandelt.)

Ziele

Es gibt eine endlose Debatte über "das ist die schnellste verteilte Anwendungstechnologie von Microsoft" oder Aussagen, dass "<Technologiename hier> einfügen ist zu langsam für uns". Das Hauptziel dieses Dokuments besteht darin, viele der Bedenken, Missverständnisse, Ungenauigkeiten und Fehlinformationen im Zusammenhang mit der Leistung verteilter Microsoft-Technologien zu behandeln und zu klären.

Unser Ziel ist es, viele derzeit behauptete Missverständnisse über die relativen Leistungsmerkmale der einzelnen verteilten Komponenten-/Diensttechnologien von Microsoft auszurotten und eine klare Reihe von illustrativen Tests und deren Ergebnisse zusammen mit einer Reihe präziser Anleitungen bereitzustellen, die Ihnen bei der Auswahl der am besten geeigneten Technologie für Ihre Anforderungen helfen.

Zusammenfassend sind unsere Ziele für dieses Papier:

1. So untersuchen Sie die relativen Leistungsunterschiede zwischen den drei Technologien für die Mehrheit der Geschäftsanwendungen
2. Korrigieren einiger Annahmen hinsichtlich der wahrgenommenen Leistungseinbußen einer Technologie gegenüber einer anderen
3. Um Ihre Entscheidungen darüber zu unterstützen, wo, wann und wie Sie die einzelnen Technologien am besten nutzen können
4. Um eine Testanwendung bereitzustellen, damit Sie diese Tests auf Ihren eigenen Computern und in Ihren eigenen Umgebungen ausführen können. Wir empfehlen Ihnen dringend, diese Testumgebung zu erstellen und auszuführen sowie die Leistungsmerkmale dieser Technologien zu untersuchen und zu analysieren. Auf diese Weise können Sie die vielen Faktoren, die sich auf die Leistung verteilter Systeme auswirken, vollständig nachvollziehen.

Dies ist kein Benchmark

Die in diesem Whitepaper vorgestellten Tests sind explizit darauf ausgelegt, konsistente Vergleichsergebnisse zwischen den zu testenden spezifischen Technologien zu liefern. Diese Tests sind nicht darauf ausgelegt, die absolute maximal mögliche Leistung für jede Technologie unter Last zu messen.

Die Testtreiberanwendung (Clientanwendung) ist singlethreaded, sodass serielle synchrone Aufrufe so schnell ausgeführt werden, wie der aufgerufene Dienst antwortet. Bei diesem Entwurf ist der Engpass nicht immer die Cpu-Auslastung des Servers.

Mehrere Clients oder ein Multithreadclient können dazu führen, dass der Server mehr Aufrufe pro Sekunde verarbeitet. Bei den CPU-intensiven Serveranwendungstests ändern mehrere Clients die absolute oder relative Leistung der getesteten Technologien nicht wesentlich.

Für die leichtesten Tests kann durch die Verwendung mehrerer Clients ein deutlich höherer aggregierter Serverdurchsatz (2X) erreicht werden. Mehrere Clients können auch die relative Leistung der verschiedenen Technologien etwas ändern.

Ob ein einzelner Client oder mehrere Clients realistischer sind, hängt davon ab, wo und wie ein Webdienst bereitgestellt wird. Die Schlussfolgerungen des Papiers bleiben von der Entscheidung, mit einem einzelnen Kunden zu messen, unberührt.

Die Tests

In den folgenden Leistungstests untersuchen wir sowohl synthetische Baselines als auch reale Szenarien. Die häufigen Fragen, die wir untersuchen möchten, sind:

1. Ist .NET Remoting schneller als ASMX?
2. Ist ES langsamer als Remoting?
3. Ist ASMX für reale Szenarien zu langsam?

• Um diese Ansprüche zu untersuchen, haben wir eine Reihe von Tests durchgeführt. Bei den primären Tests wird die Leistung von Aufrufen von Aktionen untersucht, die entweder eine große Anforderung akzeptieren und erhebliche Arbeit ausführen oder die angefordert werden, um erhebliche Arbeiten auszuführen und kleine oder große Resultsets zurückzugeben. Das Ziel dieser Tests besteht darin, die Leistung typischer Geschäftsszenarien zu veranschaulichen, die beim Erstellen Ihrer Systeme wahrscheinlich auftreten.

Alle diese Tests wurden für die protokolle der verfügbaren Technologien ausgeführt:

• Enterprise Services (mithilfe der Just-In-Time-Aktivierung)
  • Keine Authentifizierung
  • Authentifizierung auf Anrufebene und erzwungene Überprüfungen des Rollenzugriffs
• ASP.NET Webdienste
  • Keine Authentifizierung
  • Authentifizierung per Benutzername und Kennwort
  • Integrierte Authentifizierung
• .NET-Remotezugriff
  • TCP/Binary, ungesichert
  • HTTP/Binary, ungesichert
  • HTTP/SOAP, ungesichert
  • HTTP/SOAP in IIS, ungesichert
  • HTTP/Binary in IIS, ungesichert
  • HTTP/SOAP in IIS, HTTP-Standardauthentifizierung
  • HTTP/Binary in IIS, HTTP Basic Authentication
  • HTTP/SOAP in IIS, Integrierte Authentifizierung
  • HTTP/Binary in IIS, Integrierte Authentifizierung

Alle folgenden Tests basieren auf einer einzelnen Clientanwendung, die wiederholt serverseitige Methoden aufruft. Wir haben die durchschnittliche Anzahl von Remoteaufrufen/Methodenaufrufen pro Sekunde für jeden Test im Satz berechnet und den vollständigen Satz 10 Mal wiederholt, um den Durchschnitt und die Standardabweichung für einen vollständigen mehrstufigen Testlauf zu erhalten.

Das Ergebnis

Test 1: Erstellen und Speichern von Aufträgen

Dieser erste Test wurde entwickelt, um die Leistungsmerkmale zu simulieren, die jede Technologie im optimalsten Fall aufweist – wenn die aufgerufene Aktion erhebliche Arbeit leistet. Um erhebliche Arbeit zu leisten, speichert die aktion, die aufgerufen wird, Bestellungen in einer Datenbank, in der Datensätze in zwei Tabellen innerhalb einer Transaktion geschrieben werden.

Der Aufrufer erstellt eine instance der folgenden Order-Klasse.

[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;
}

Die Order-Klasse enthält ein untergeordnetes Objekt vom Typ Address und ein Array von 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;
}

Dieses Datenobjekt wird vom Aufrufer an den Server während des Methodenaufrufs übergeben und von den verschiedenen getesteten Technologien auf den Draht serialisiert.

Die serverseitige Implementierung ähnelt der folgenden:

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();
   }
}

Nachdem der Testlauf abgeschlossen ist, verwendet die serverseitige Logik eine zweite Transaktion, um die eingefügten Datensätze zu löschen, sodass unabhängig davon, wie oft dieser Test ausgeführt wird, ein "level playing field" (gleiches Spielfeld) bereitstellt.

Abbildung 1. Übergeben eines computerübergreifenden Auftrags mit einer echten serverseitigen Implementierung

Wenn Sie sich die Testergebnisse in Abbildung 1 ansehen, beachten Sie, dass es nur einen Unterschied von 14 % zwischen ES @73 CPS und ASP.NET Webdiensten @63 CPS gibt und dass der maximale Unterschied zwischen den schnellsten und den langsamsten Protokollen 45 % beträgt. Dies zeigt deutlich, dass der Nutzen eines bestimmten Transports gegenüber einem anderen abnimmt, da die geleistete Arbeit proportional zur Zeit, die für den Transport von Daten dauert, wächst.

Außerdem haben wir einen übereinstimmenden ADO.NET DataSet-Test erstellt und typisierte DataSets erstellt, die DataTables enthalten, die wie in Abbildung 2 definiert sind.

Abbildung 2. Dieses DataSet stellt eine Bestellung dar.

Dieses DataSet wird mit einem generierten SqlDataAdapter verwendet, einschließlich SqlCommands, die denen in den obigen Codeausschnitten ähneln.

Wenn die Reihenfolge vom Aufrufer als DataSet an den Server übergeben und dann gespeichert wird, erhalten wir die in Abbildung 3 dargestellten Ergebnisse.

Abbildung 3. Speichern einer Bestellung als DataSet

Beachten Sie die erheblichen Auswirkungen auf die Leistung der Verwendung von DataSets (um etwa 50 % verlangsamt), zusammen mit der Tatsache, dass der Unterschied zwischen den Protokollen noch weiter abnimmt. Es ist auch wichtig zu beachten, dass die langsamsten Ergebnisse der Übergabe von Datenobjekten die beste Leistung beim Übergeben ADO.NET DataSets übersteigen.

Dies zeigt deutlich, dass das Übergeben ADO.NET DataSets zwischen den Ebenen eines Systems zu erheblichen Leistungseinbußen führt.

Test 2: Abrufen von Northwind-Produktdaten

Der Zweck dieses Tests besteht darin, die Leistungsmerkmale jeder Technologie zu veranschaulichen, wenn eine relativ große Menge an Daten von einem Dienst zurückgegeben wird, der keine erhebliche Arbeit ausführt.

Zum Modellieren dieses Szenarios haben wir Methoden erstellt, die eine Liste von "Produktdatensätzen" aus der bekannten SQL Server Beispieldatenbank "Northwind" abrufen und zurückgeben.

Wir erwarten, dass die binären Serialisierungstechnologien (ES/COM+ und Remoting Binary/TCP) bei diesem Test am besten abschneiden. wir erwarten auch, dass die SOAP-basierten Technologien aufgrund der größeren Datenmengen, die transportiert werden, sowie ihre komplexeren Serialisierungs- und Deserialisierungsmechanismen niedrigere Leistungsniveaus erzielen werden.

Im ersten Test haben wir eine [Serializable] Klasse definiert, die über öffentliche Member verfügt, die mit dem XML-Serialisierungsprogramm kompatibel sind:

[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;
}

In der serverseitigen Implementierung öffnen wir eine Datenbankverbindung mit SQL Server, haben eine Abfrage für die Datenbank ausgeführt und mithilfe eines ADO.NET SqlDataReader eine ArrayList mit 77 Product-Instanzen dieser Klasse aufgefüllt. Die ArrayList wurde dann an den Aufrufer zurückgegeben.

Die Ergebnisse sind in Abbildung 4 dargestellt.

Abbildung 4. Abrufen des Northwind-Produktkatalogs als Objekte

Diese Ergebnisse zeigen, dass Enterprise Services (über DCOM) und TCP-basiertes binäres Remoting gleiche Leistungsstufen für ungesicherte Aufrufe bieten. Die Ergebnisse zeigen auch, dass ASP.NET Webdienste etwa 62 % der Leistung von Enterprise Services bieten und dass die langsamsten Protokolle nur 17 % der Anzahl der Anrufe pro Sekunde im Vergleich zu den schnellsten zulassen.

In diesen und allen folgenden Tests wird deutlich, warum es im Allgemeinen nicht empfohlen wird, .NET Remoting SoapFormatter zum Erstellen von SOAP-Diensten zu verwenden: Der ASP.NET Webdienststapel ist etwa dreimal so schnell.

Im zweiten Ansatz für diesen Test haben wir eine Methode implementiert, die die angeforderten Daten in einem ADO.NET DataSet-Objekt zurückgibt, das direkt auf dem zugrunde liegenden Tabellenlayout basiert, und die DataSet-DataTable mithilfe eines SqlDataAdapter auffüllen. Die Tabellendefinition ist in Abbildung 5 dargestellt.

Abbildung 5. Das typisierte DataSet für den Zugriff auf den Produktkatalog

Abbildung 6 veranschaulicht die Ergebnisse:

Abbildung 6. Abrufen des Northwind-Produktkatalogs als DataSet

Aus den Ergebnissen dieses Tests geht hervor, dass die Rückgabe von DataSets vom Dienst an den Aufrufer die Leistung erheblich verringert – um etwa 75 % für die binären Transporte! Beachten Sie auch, dass die Leistung der vier schnellsten Protokolle vollständig identisch ist, was bedeutet, dass alle vier Technologien durch die Serialisierung, Deserialisierung und den Transport des DataSet gedrosselt wurden. Beachten Sie außerdem, dass der Leistungsbereich zwischen den schnellsten (ASMX @ 39 Cps) und den langsamsten (integrierte Sicherheit von Remoting HTTP/SOAP (IIS) bei 25 Cps) durch nur 14 Cps getrennt ist – ein Rückgang von lediglich 30 %.

Dies veranschaulicht, dass es zwar praktisch ist, DataSets zu verwenden, um Informationen zwischen den Ebenen Ihrer Anwendungen zu übergeben, dies jedoch erhebliche Auswirkungen auf die Leistung hat. Wir werden zu diesem Thema später zurückkehren.

Es ist auch wichtig, darauf hinzuweisen, dass es schneller ist, ein ADO.NET DataSet zu durchlaufen und eine Sammlung von Datenobjekten zu erstellen und diese Sammlung zu serialisieren, als nur die ADO.NET DataSet an den Aufrufer zurückzugeben! Wenn dies ein echtes System wäre, das implementiert wurde, um DataSets zwischen Server und Aufrufer zu übergeben, könnten wir die Leistung dieses Teils des Systems mit nur einem geringen Arbeitsaufwand fast vervierfachen.

Test 3: Abrufen von Kundeninformationen

Im nächsten Test wollten wir die relativen Leistungsmerkmale jeder Technologie bei der Übertragung einer sehr kleinen Datenmenge vom Server auf den Client untersuchen, indem wir einen einzelnen Kundendatensatz aus der Beispieldatenbank "Northwind" SQL Server abrufen.

Wir haben die folgende [Serializable] Customer-Klasse erstellt, um die abgerufenen Daten vom Server zurück an den Client zu übertragen:

[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;
}

Im Folgenden wird ein Teil unserer serverseitigen Implementierung gezeigt, der einen SqlDataReader verwendet, um eine neue instance der Customer-Klasse aufzufüllen:

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;
         }
      }
   }
}

Die Ergebnisse unseres Leistungsvergleichs sind in Abbildung 7 dargestellt.

Abbildung 7. Abrufen der Daten eines Kunden als Objekt

Diese Ergebnisse heben die Leistungsunterschiede zwischen den einzelnen zugrunde liegenden Technologien deutlicher hervor. Diese Differenzen sind in diesem Test so sichtbar, da die Arbeit, die zum Abrufen und Zurückgeben eines einzelnen Datensatzes geleistet wird, einen viel niedrigeren Prozentsatz der Gesamtkosten für Anrufe ist und daher die Transportkosten eine größere Rolle spielen. Da SOAP/HTTP höhere Transportkosten als binär/DCOM hat, weisen die SOAP-Transporte einen viel niedrigeren Durchsatz auf als die binären Mechanismen.

Als Nächstes haben wir den gleichen Vorgang getestet und ein typisiertes DataSet zurückgegeben, wie in Abbildung 8 dargestellt.

Abbildung 8. Das typisierte DataSet für den Zugriff auf die Informationen eines Kunden

Dieses DataSet wird mithilfe einer serverseitigen Implementierung wie der folgenden aufgefüllt:

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;
   }
}

Beim Ausführen dieses Codes in unserem Testframework haben wir die in Abbildung 9 dargestellten Ergebnisse erhalten.

Abbildung 9. Abrufen der Daten eines Kunden als DataSet

Ähnlich wie bei den vorherigen Tests ist klar, dass sich der Austausch ADO.NET DataSets negativ auf die Leistung auswirkt, und der Unterschied im Durchsatz für alle Technologien kleiner wird als bei der Rückgabe serialisierter Objekte, die veranschaulichen, dass ADO.NET DataSets den Durchsatz drosseln.

leistung von .NET Framework 2.0

Zum Zeitpunkt der Erstellung dieses Papiers arbeitet Microsoft daran, die .NET Framework 2.0 (zuvor mit dem Codenamen "Whidbey") bereitzustellen, die eine Vielzahl von Verbesserungen, Verbesserungen und neuen Funktionen enthält, einschließlich:

• Vollständige Unterstützung für x64- und IA64-basierte Computer
• Brandneue Transaktionsunterstützung über System.Transactions
• Viele Verbesserungen an System.Net einschließlich Konnektivitätsbewusstsein und Unterstützung für Proxys
• Erhebliche Verbesserungen für Windows Forms und Web Forms
• Infrastruktur für die automatische Anwendungsbereitstellung "ClickOnce"

Zusätzlich zu den neuen und erweiterten Features, die im .NET Framework 2.0 enthalten sind, wurde viel Arbeit geleistet, um die Leistung erheblich zu steigern und die Speicherauslastung in vielen Bereichen zu verbessern, einschließlich BCL, XML-Serialisierung, Netzwerkdurchsatz, ADO.NET, ASP.NET usw.

Erste Beispiele für diese Leistungs- und Durchsatzverbesserungen finden Sie in den folgenden Whitepapern:

• Vergleichen der XML-Leistung

  .NET Framework 2.0 Beta 2, .NET Framework 1.1 und Sun Java 1.5-Plattformen

• Vergleichen der Webdienstleistung

  WS-Test 1.1-Benchmarkergebnisse für die .NET Framework 2.0, .NET 1.1, Sun JWSDP 1.5 und IBM WebSphere 6.0

Weitere Whitepaper zur Leistungsanalyse und Vergleiche werden in den kommenden Monaten veröffentlicht, da die .NET Framework 2.0 ihren Weg in Richtung RTM (Release to Manufacturing) fortsetzt. Um mit solchen Whitepapern auf dem neuesten Stand zu bleiben, besuchen Sie bitte die folgenden Online-Ressourcen:

• Das .NET Framework Developer Center
• Wettbewerbsfähige Berichte und Nachweise: Vergleich von .NET mit J2EE

Zusammenfassung

Die Ergebnisse der oben genannten realen Tests sind in Tabelle 1 dargestellt.

Tabelle 1. Ergebniszusammenfassung

Aufrufe pro Sekunde (gerundet)	Enterprise Services	ASP.NET-Webdienste	.NET Remoting TCP Binary
Test 1: Speichern von Bestellungen a) Serialisierte Daten b) DataSet	73 35	63 34	72 34
Test 2: Abrufen von Produkten a) Serialisierte Daten b) DataSet	147 39	93 39	149 39
Test 3: Abrufen des Kunden a) Serialisierte Daten b) DataSet	618 90	289 83	682 91

Diese Ergebnisse zeigen die Leistungsmerkmale, die Sie von realen Anwendungen erwarten können, und dass der Unterschied zwischen Webdiensten (die in der Regel als sehr langsam wahrgenommen werden) und DCOM (die eindeutig eine der schnellsten verteilten Anwendungstechnologien in diesem Test ist) für reale Anwendungen sehr gering ist.

Unsere Beobachtungen zu den getesteten Technologien werden im folgenden Abschnitt ausführlicher erläutert, können aber hier zusammengefasst werden:

• Obwohl ASMX nicht unbedingt die schnellste Technologie ist, die wir derzeit liefern, ist ihre Leistung für die meisten Geschäftsszenarien mehr als angemessen. In Kombination mit den Tatsachen, dass ASMX-Dienste einfach zu skalieren sind und eine Fülle weiterer Vorteile wie Interoperabilität und zukünftige Kompatibilität bieten, sollte ASMX heute Ihre primäre Wahl für Gebäudedienstleistungen sein.
• Wenn die absolute Leistung von größter Bedeutung ist, sollten Enterprise Services-Komponenten verwendet werden, um die leistungskritischsten Teile Ihres Systems zu erstellen. COM+ hat insgesamt am besten abgeschnitten und ist eine sichere und zuverlässige Hostingumgebung für verteilte Komponenten. ES/COM+ lässt sich auch gut in Indigo-Dienste integrieren, und es wird relativ einfach sein, ES-Komponenten in Indigo-Dienste zu konvertieren.
• Während .NET Remoting bei verwendung der binären Serialisierung über TCP sehr gut funktioniert, verringert sich die Leistung, wenn Remotingkomponenten in IIS gehostet werden und/oder beim Senden und Empfangen von SOAP-Nachrichten. In Kombination mit der Tatsache, dass .NET Remoting-Komponenten mit nichts anderem als .NET Remoting-Endpunkten zusammenarbeiten, sollten Sie nach Möglichkeit ASMX oder ES vor Remoting in Betracht ziehen.

Eine wichtige Beobachtung, die aus diesen Ergebnissen gezogen werden sollte, ist, dass die Transportzeit einen erheblichen Teil der Anrufzeit auszahlt, wenn die auf dem Server ausgeführte Arbeit nicht einen signifikanten Prozentsatz der Gesamtdauer jedes Anrufs darstellt. Wenn Sie von einem "schnellen" Transport (z. B. DCOM unter COM+) zu einem "kostspieligeren" Transport (z. B. SOAP/HTTP unter ASMX) wechseln, kann es zu erheblichen Auswirkungen auf die Leistung kommen. Daher ist unsere Anleitung, bei jedem Methodenaufruf so viel Wie möglich auf dem Server auszuführen und unnötige Netzwerkdurchläufe zu vermeiden, übersichtlich dargestellt.

Die Leistungsvorteile dieser Technologien gegenüber anderen nehmen ab, wenn der Arbeitsaufwand, der vom aufgerufenen Dienst ausgeführt wird, zunimmt. Diese Beobachtung wurde in vielen Artikeln beschrieben, einschließlich der Leistung von .NET Enterprise Services.

Aus diesen Tests geht auch hervor, dass die Leistungsunterschiede zwischen diesen Technologien kleiner sind als die Unterschiede zwischen anwendungsspezifischen Entscheidungen wie der Verwendung von DataSets oder serialisierten Strukturen.

Obwohl wir uns in diesem Papier stark auf die Leistungszahlen konzentriert haben, ist die Leistung nicht der einzige Faktor, den Sie bei der Planung Ihrer Entwicklungsprojekte berücksichtigen sollten. Andere Faktoren wie Sicherheit, Skalierbarkeit, Verwaltung, Entwicklerproduktivität, Interoperabilität und die zukünftige Ausrichtung verteilter Microsoft-Technologien spielen eine Rolle. Die Entwicklung verteilter Dienste heute enthält einen präskriptiven Leitfaden, wie Sie am besten auswählen können, wann und wo die einzelnen Technologien eingesetzt werden und was die Zukunft bereithält.

Empfehlungen

Basierend auf den Ergebnissen dieser Tests und in Übereinstimmung mit unserer zukünftigen Technologierichtung und bewährten Methoden können Sie Systeme erstellen, die nicht so anfällig für Leistungsprobleme sind, indem Sie die folgenden Empfehlungen einhalten:

Verwenden von ASMX, wo immer möglich

Um die größtmögliche Reichweite für Ihre Dienste zu bieten, sollten Sie Ihre Dienste nach Möglichkeit mithilfe von ASMX veröffentlichen. Dadurch kann jedes System, das SOAP über HTTP kommunizieren kann, Ihren Dienst aufrufen, unabhängig davon, auf welcher Plattform, auf welchem Gerät oder in welcher Sprache das System ausgeführt oder implementiert wird. Wie Sie anhand der obigen Ergebnisse sehen können, ist ASMX in vielen Szenarien bewundernswert. Selbst auf unserem Einzelprozessorcomputer, der von einer Singlethread-Anwendung aufgerufen wird, ist ASMX in der Lage, etwa 63 schwere Vorgänge pro Sekunde zu verarbeiten – nur 10 Aufrufe pro Sekunde weniger als die entsprechende ES-Komponente! In einer Produktionsumgebung können Sie deutlich mehr Leistung von einer einzelnen Box erwarten, die ASMX-Dienste hosten, sodass die ASMX-Leistung Ihre Einführung dieser wichtigen Technologie nicht blockieren sollte.

Webdienste weisen andere nützliche Merkmale und Features auf, einschließlich (aber nicht beschränkt auf):

• Skalierbarkeit: Es ist sehr einfach, einen Webdienst mithilfe von Lastenausgleichstechnologie wie Windows-Netzwerklastenausgleich oder Hardwaregeräten von Anbietern wie Cisco und F5 hochzuskalieren. Weitere Informationen zu diesem Thema folgen.
• Verfügbarkeit– ASMX-Webdienste können mithilfe einer Kombination von Technologien wie lastenausgleich in Kombination mit den leistungsstarken Funktionen der in Windows 2003 Server integrierten IIS6-Infrastruktur (z. B. automatisches Recycling und Neustarten fehlerhafter Dienste) so konfiguriert werden, dass sie hochverfügbar sind.
• Interoperabilität: Webdienste bilden den Kern der Vereinheitlichung von interoperablen sicheren, zuverlässigen, transaktionsbasierten Kommunikationsprotokollen, die die freie Kommunikation unterschiedlicher, heterogener Systeme ermöglichen.
• Produktivität: Das Erstellen von ASMX-Webdiensten ist für die meisten Entwickler durch die vernünftige Verwendung einiger Attribute und das Befolgen einiger Empfehlungen sehr einfach.

Verwenden von ASMX für Webdienste

Es gibt viele Gründe, warum ASMX eine hervorragende Plattform zum Erstellen und Bereitstellen von Diensten ist, wie in der präskriptiven Anleitung beschrieben, und wie aus den Ergebnissen in diesem Dokument ersichtlich ist, übertrifft ASMX in der Regel Remoting, wenn SOAP gesprochen wird.

Es ist auch wichtig zu beachten, dass.NET-Remoting zwar SOAP/HTTP (über SoapFormatter und HttpChannel) unterstützen kann, wir jedoch davon ab raten, Remoting zum Verfügbarmachen von Webdiensten zu verwenden. Der .NET Remoting SoapFormatter verwendet RPC-Encoding, die nicht mehr die Standardmethode für die SOAP-Codierung ist (dokumentliteral ist der zukünftige Standardcodierungsmechanismus, der von den Technologien und Plattformen der meisten Anbieter verwendet wird); Daher ist die Interoperabilität mit Remoting-Diensten sehr eingeschränkt.

Auswählen von Webdiensten für Skalierbarkeit

Eine Sache, die oben nicht veranschaulicht wurde, aber für diese Diskussion sehr relevant ist, ist, dass Webdienste in erster Linie über HTTP sprechen, eine zustandslose Kommunikationstechnologie, die einfach zu lastenausgleichen ist. Dies bedeutet, dass es auch möglich ist, zustandslose Remotingkomponenten mithilfe von TCP oder HTTP (d. h. in IIS gehostet) zu lasten, obwohl dies komplex und problematisch werden kann, wenn der Sitzungszustand erforderlich ist.

Zum Lastenausgleich von ES/COM+-Komponenten müssen Sie den Komponentenlastenausgleich (Component Load Balancing, CLB) verwenden, ein Feature von Application Center 2000. Leider tritt AppCenter 2000 im Juli 2006 in den erweiterten Support ein, und der Support endet im Jahr 2011. Um zu vermeiden, dass Sie Ihre Systeme lange vor 2011 neu entwerfen müssen, um nicht mehr von CLB abhängig zu sein, ist es daher dringend ratsam, diese Technologie für neue Entwicklungen zu vermeiden und stattdessen so schnell wie möglich zu anderen Strategien zu migrieren. Eine gute Migrationsstrategie besteht darin, Ihre aktuellen COM+-Komponenten mit ASMX-Webdiensten zu versehen, die Aufrufe einfach direkt an die COM+-Komponente übergeben und wie oben beschrieben einen Lastenausgleich für Ihre Webdienste durchführen.

Verwenden von Enterprise Services nur innerhalb Ihrer Dienste

.NET Enterprise Services ist eine Ebene der .NET Framework, die Zugriff auf und Unterstützung für die von COM+ angebotenen umfassenden Dienste bietet. Wenn Sie einen der umfangreichen COM+-Dienste benötigen, z. B. verteilte Transaktionen, die mehrere Objekte/Dienste umfassen, differenzierte Sicherheit, JITA und Objektpooling, dann sollten Sie Enterprise Services auswählen. Enterprise Services und COM+ sind gut getestete, hochoptimierte Technologien, die extrem schnelle, prozess- und computerübergreifende Aufrufe mit geringer Latenz ermöglichen.

Es wird jedoch dringend empfohlen, Ihre Enterprise Services-Komponenten nicht allgemein verfügbar zu machen und diese Technologie nur innerhalb Ihrer Dienstgrenze zu verwenden. Wenn Sie Zugriff auf Ihren Dienst gewähren möchten, empfehlen wir Ihnen, die Funktionen Ihres Diensts über Webdienste mit ASMX verfügbar zu machen. Wenn Sie über eine etablierte ES/COM+-Codebasis verfügen, empfehlen wir, Ihre COM+-Dienste nach Möglichkeit mit ASMX-Webdiensten zu versehen.

Erwägen Sie eine gehostete Infrastruktur, statt ihre eigene zu erstellen.

Wie oben zu sehen ist, bietet ASP.NET leistungsstarke Webdienste, die sehr interoperabel sind und auch von den großartigen Hostingfunktionen profitieren, die von IIS bereitgestellt werden – insbesondere IIS6 in Windows 2003 Server.

COM+ bietet die schnellste Komponentenleistung auf der Microsoft-Plattform und ist eine bewährte, vertrauenswürdige, sichere, sichere und zuverlässige Hostingumgebung für Ihre Enterprise Services- und COM+-Komponenten. Darüber hinaus bietet es Unterstützung für verteilte Transaktionen, Sicherheit (Authentifizierung und Verschlüsselung), Zuverlässigkeit, Verfügbarkeit und Verwaltungsdienste und ist eine gute Wahl zum Hosten komplexer komponentenbasierter Systeme in Ihrem Dienst.

.NET-Remoting mit binärer Serialisierung über TCP bietet zwar auch eine hervorragende Leistung, bietet jedoch keine "sofort einsatzbereiten" Features für Die Hostingumgebung, Sicherheit, Zuverlässigkeit, Verfügbarkeit oder Verwaltung. Um Remoting-Komponenten zu hosten, die TCP verwenden, müssen Sie Ihre eigene (sichere, skalierbare, zuverlässige) Hostinganwendung schreiben, und dies ist keine triviale Aufgabe. Wenn Sie Remoting über HTTP verwenden möchten, können Sie optional IIS als Host verwenden, aber wie Sie sehen können, wirkt sich das Hosten Ihrer Remoting-Komponente in IIS und das Kommunizieren von SOAP/HTTP erheblich auf die Remotingleistung aus – oft bis zu dem Punkt, an dem ASMX besser abschneidet!

Daher sollten Sie erwägen, Ihre Dienste in ASMX bereitzustellen, die in IIS- oder Enterprise Services-Komponenten innerhalb von COM+ gehostet werden, anstatt Remoting nach Möglichkeit zu verwenden.

Vermeiden der Übergabe von DataSets zwischen Diensten

In unseren Tests führte die Auswahl der Art und Weise, wie die Dienste und Aufrufer Daten austauschen – als DataSets oder serialisierte Strukturen – zu einer viel größeren Auswirkung auf die Leistung als die Wahl einer bestimmten verteilten Systemtechnologie gegenüber einer anderen.

Aus Leistungssicht fordern wir Sie dringend auf, Ihre Verwendung von DataSets als Datenübertragungsmechanismus auf die Teile Ihrer Anwendung zu beschränken, in denen sie wirklich benötigt werden, und dass Sie sich nach Möglichkeit für [serialisierbare] Strukturen entscheiden.

ADO.NET DataSets bieten eine hervorragende Möglichkeit, Daten abzurufen, zu bearbeiten, zu sortieren und zu formen, sie lokal für die Offlineverwendung zu speichern und Änderungen wieder in einer zentralen Datenbank zu synchronisieren. Wenn dies eine Anforderung Ihrer Anwendung ist, ist dies natürlich eine gültige Wahl. Im .NET Framework 1.x werden DataSet-Werte immer in XML serialisiert (auch wenn Sie angeben, dass sie als binär serialisiert werden sollen oder sie mit ES oder Remoting verwenden möchten), und sie enthalten auch die XSD, die die Daten beschreibt. Dies wirkt sich natürlich auf die Leistung aus.

Denken Sie darüber hinaus daran, dass DataSets ein sind. NET-spezifische Technologie und schränkt Ihre Interoperabilität erheblich ein, da andere Plattformen nicht unbedingt in der Lage sind, Daten zu serialisieren und zu analysieren, die serialisierte DataSets enthalten.

Sie können erhebliche Leistungsverbesserungen erzielen, indem Sie stattdessen serialisierte Datenstrukturen austauschen. Das integrierte Runtimeformatierungs- und XML-Serialisierungsframework erleichtert dies, wie in den obigen Tests gezeigt.

Verwenden der authentifizierten Verbindungsfreigabe

Alle Tests, die InternetInformationsserver als Host in Verbindung mit integrierter Sicherheit verwenden, wurden für die Ausführung mit den Optionen useAuthenticatedConnectionSharing und useUnsafeAuthenticatedConnectionSharing konfiguriert, die für ASP.NET Clients und .NET Remoting verfügbar sind. Mit dieser Einstellung können Client und Server eine vorhandene NTLM-authentifizierte Verbindung wiederverwenden.

Sie können die Leistungsergebnisse sehen, wenn wir diese Option in Abbildung 10 während der Tests festlegen, die ursprünglich in Abbildung 1 (Speichern einer Bestellung als Objekte) dargestellt wurden. Beachten Sie, dass diese Einstellung nur wirksam ist, wenn Sie internetinformationsserver (IIS) als Server verwenden und wenn Sie "Windows In Security" in der Konfiguration Ihres virtuellen Verzeichnisses festlegen.

In der Spalte Web Q&A: Caching Transforms, Connection Sharing und More in der Ausgabe des MSDN Magazine vom September 2004 werden diese Kompromisse erläutert.

Abbildung 10. Die Auswirkungen von UnsafeAuthenticatedConnectionSharing

Sie können die integrierte Windows-Sicherheit zusammen mit dieser Einstellung in ASP.NET Webdiensten wie folgt verwenden:

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

Und mit .NET Remoting wie folgt:

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

Anhang A: Synthetische Baseline – Test der leeren Methode

Dieser Test "baselines" die Leistungsunterschiede zwischen den zugrunde liegenden Technologien, die untersucht werden. Diese Tests führen Aufrufe für Aktionen aus, die keine Parameter akzeptieren, keine Arbeit ausführen und keine Ergebnisse zurückgeben. Die serverseitige Implementierung ist so einfach wie:

public void TransferEmpty()
{
   // do nothing
}

Hinweis Es ist wichtig, daran zu erinnern, dass diese synthetischen Basiswerte nur zur Veranschaulichung des relativen Leistungsniveaus der Kommunikationsinfrastruktur der einzelnen zu untersuchenden Technologien vorgelegt werden und nicht die in realen Systemen erwarteten Leistungsmerkmale widerspiegeln.

Abbildung 11. Aufrufen einer Methode ohne Parameter prozessübergreifend (synthetische Baseline)

Die Ergebnisse unserer Tests in Abbildung 11 entsprachen den gängigen Annahmen sehr gut: ES bietet aufgrund seiner Abhängigkeit von COM+ und DCOM und der leistungsstarken LPC (Lightweight Procedure Call) On-Box-Kommunikationsinfrastruktur mit Abstand die beste Leistung. .NET Remoting-Kabelprotokolle kommen an zweiter Stelle. ASP.NET Webdienste kommen an dritter Stelle, sind aber immer noch schneller als .NET Remoting-Komponenten, die in IIS gehostet werden.

Im zweiten Schritt haben wir diesen Test computerübergreifend ausgeführt. Wir haben die generierte ASP.NET umgeleitet, indem wir die Eigenschaft "Url" festgelegt haben, einen Anwendungsproxy für die COM+/Enterprise Services-Komponenten exportiert und Activator.GetObject() für den .NET Remoting-Teil dieses Tests verwendet haben. Die Ergebnisse entsprechen sehr stark den vorherigen Tests, aber mit etwas geringerer Anzahl von Anrufen pro Sekunde aufgrund der beteiligten Netzwerkdurchläufe:

Abbildung 12: Aufrufen einer leeren Methode ohne parameterübergreifender Parameter (synthetische Baseline)

Beachten Sie, dass die computerübergreifende Netzwerkdurchquerung im Wesentlichen die schnellsten Transporte (ES und Remoting Binary/TCP) gedrosselt hat, während die langsameren Transporte kaum beeinträchtigt werden. Dies zeigt deutlich, wie effektiv insbesondere die prozessübergreifenden Kommunikationsmechanismen von COM+ im Vergleich zu den Technologien sind, die hauptsächlich für die Bereitstellung von Netzwerkdatenverkehr (d. h. IIS & ASMX) entwickelt wurden.

Es ist wichtig, sich daran zu erinnern, wie oben erwähnt, dass dieser Test sehr künstlich ist und nur die Fähigkeiten der Transporte veranschaulicht.

Anhang B – Detaillierte Testergebnisse

Bestellung als Objekt speichern

Test	Durchschnittliche Aufrufe/Sekunde	Std. Abweichung
Enterprise Services	73	0.39
Enterprise Services (Authentifizierung)	73	0.34
Remoting TCP/Binary	72	2.71
Remoting HTTP/Binary	68	0.86
Remoting VON HTTP/Binary (IIS)	66	0.31
ASP.NET Webdienste	63	2.71
Remoting-HTTP/Binary-Kennwort (IIS)	63	0.39
Remoting TCP/SOAP	56	1.97
Remoting HTTP/SOAP	53	0,57
Integriertes Remoting von HTTP/Binary (IIS)	51	0.28
Remoting HTTP/SOAP (IIS)	50	0.16
ASP.NET Webdienste – Integriert	50	0,30
Remoting-HTTP/SOAP-Kennwort (IIS)	49	0,29
Integriertes Remoting von HTTP/SOAP (IIS)	40	0.84

Bestellung als DataSet speichern

Test	Durchschnittliche Aufrufe/Sekunde	Std. Abweichung
Enterprise Services	35	0,54
Enterprise Services (Authentifizierung)	35	0.51
ASP.NET Webdienste	34	0.43
Remoting TCP/Binary	34	0.85
Remoting HTTP/Binary	32	0.77
Remoting VON HTTP/Binary (IIS)	32	1.10
Remoting TCP/SOAP	32	0.77
Remoting-HTTP/Binary-Kennwort (IIS)	31	1.47
Remoting HTTP/SOAP	30	0,68
Remoting HTTP/SOAP (IIS)	30	0,48
Remoting-HTTP/SOAP-Kennwort (IIS)	30	0,46
ASP.NET Webdienste – Integriert	29	0,37
Integriertes Remoting von HTTP/Binary (IIS)	28	0,37
Integriertes Remoting von HTTP/SOAP (IIS)	26	0.31

Laden von Produkten als Objekte

Test	Durchschn. Aufrufe/Sekunde	Std. Abweichung
Remoting TCP/Binary	149	3.05
Enterprise Services	147	2.29
Enterprise Services (Authentifizierung)	146	2.49
Remoting HTTP/Binary	118	2,13
Remoting HTTP/Binary (IIS)	114	0,63
Remoting-HTTP/Binary-Kennwort (IIS)	106	1.19
ASP.NET-Webdienste	93	1,04
Integriertes Remoting von HTTP/Binary (IIS)	76	0.81
ASP.NET Webdienste – Integriert	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-Kennwort (IIS)	29	0.16
Integriertes Remoting von HTTP/SOAP (IIS)	26	0.14

Laden von Produkten als DataSet

Test	Durchschn. Aufrufe/Sekunde	Std. Abweichung
ASP.NET-Webdienste	39	0,12
Enterprise Services	39	0.26
Enterprise Services (Authentifizierung)	39	0,21
Remoting TCP/Binary	39	1.16
Remoting HTTP/Binary (IIS)	36	0.24
Remoting HTTP/Binary	35	1.10
Remoting-HTTP/Binary-Kennwort (IIS)	35	0.17
ASP.NET Webdienste – Integriert	33	0.09
Integriertes Remoting von HTTP/Binary (IIS)	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-Kennwort (IIS)	28	0.06
Integriertes Remoting von HTTP/SOAP (IIS)	25	0,08

Laden des Kunden als Objekt

Test	Durchschn. Aufrufe/Sekunde	Std. Abweichung
Remoting TCP/Binary	682	12.32
Enterprise Services	618	13.78
Enterprise Services (Authentifizierung)	616	7.76
Remoting HTTP/Binary	406	7.84
Remoting TCP/SOAP	359	11.62
Remoting HTTP/Binary (IIS)	324	4.26
ASP.NET-Webdienste	289	2.68
Remoting HTTP/SOAP	267	6,18
Remoting-HTTP/Binary-Kennwort (IIS)	261	2,39
Remoting HTTP/SOAP (IIS)	214	2.84
Remoting-HTTP/SOAP-Kennwort (IIS)	186	0.81
Integriertes Remoting von HTTP/Binary (IIS)	134	0.95
ASP.NET Webdienste – Integriert	130	0,67
Integriertes Remoting von HTTP/SOAP (IIS)	112	0,55

Laden des Kunden als DataSet

Test	Durchschn. Aufrufe/Sekunde	Std. Abweichung
Remoting TCP/Binary	91	2.69
Enterprise Services	90	0,30
Enterprise Services (Authentifizierung)	90	0.26
ASP.NET-Webdienste	83	0.24
Remoting HTTP/Binary	80	0,67
Remoting TCP/SOAP	78	1,04
Remoting HTTP/Binary (IIS)	78	0.22
Remoting-HTTP/Binary-Kennwort (IIS)	75	0.26
Remoting HTTP/SOAP	71	0,92
Remoting HTTP/SOAP (IIS)	67	0.34
Remoting-HTTP/SOAP-Kennwort (IIS)	64	0,20
ASP.NET Webdienste – Integriert	62	0.14
Integriertes Remoting von HTTP/Binary (IIS)	59	0,15
Integriertes Remoting von HTTP/SOAP (IIS)	52	0,13

Leere Nachricht, prozessübergreifend

Test	Durchschn. Aufrufe/Sekunde	Std. Abweichung
Enterprise Services	14687	52.66
Enterprise Services (Authentifizierung)	12293	31.71
Remoting TCP/Binary	3538	38.87
Remoting HTTP/Binary	1069	8.05
Remoting TCP/SOAP	1075	11.87
Remoting HTTP/SOAP	612	7,88
Remoting VON HTTP/Binary (IIS)	589	1,83
ASP.NET Webdienste	517	1.44
Integriertes Remoting von HTTP/Binary (IIS)	451	1.19
Remoting-HTTP/Binary-Kennwort (IIS)	421	0.90
Remoting HTTP/SOAP (IIS)	406	1,76
ASP.NET Webdienste – Integriert	403	0,76
Integriertes Remoting von HTTP/SOAP (IIS)	336	0,57
Remoting-HTTP/SOAP-Kennwort (IIS)	321	0,37

Leere Nachricht. Computerübergreifend

Test	Durchschnittliche Aufrufe/Sekunde	Std. Abweichung
Enterprise Services (Authentifizierung)	3068	25.35
Enterprise Services	3048	38.24
Remoting TCP/Binary	2609	77.28
Remoting TCP/SOAP	760	31.65
Remoting HTTP/Binary	704	8.00
Remoting VON HTTP/Binary (IIS)	479	2.60
Remoting HTTP/SOAP	413	10.63
ASP.NET Webdienste	399	2.00
Remoting-HTTP/Binary-Kennwort (IIS)	351	1.98
Remoting HTTP/SOAP (IIS)	309	1.38
Remoting-HTTP/SOAP-Kennwort (IIS)	252	1,25
Integriertes Remoting von HTTP/Binary (IIS)	156	0,52
ASP.NET Webdienste – Integriert	150	0,57
Integriertes Remoting von HTTP/SOAP (IIS)	133	0.28

Anhang C: Testanwendungshinweise

Ausführen der Testanwendung

Sie können die Testanwendung an dem am Anfang dieses Artikels angegebenen Speicherort herunterladen. Zum Ausführen dieser Tests auf Ihrer eigenen Hardware benötigen Sie mindestens zwei Computer: einen Client und einen Server. Darüber hinaus benötigen Sie Zugriff auf eine SQL Server Installation, die die Northwind-Beispieldatenbank enthält. Eine schrittweise Anleitung zum Bereitstellen, Konfigurieren und Ausführen dieser Testsuite finden Sie in der Datei README.TXT, die Teil des ZIP-Archivs ist, das den Quellcode enthält.

Interessant: Die Test-App ist technologieunabhängig!

Sie sehen in der Testanwendung, dass es möglich ist, transportunabhängige Anwendungen zu erstellen. In der Beispielanwendung finden Sie eine Methode Test.CreateProxy(), die einen Verweis auf einen Remotedienst erstellt und einen clientseitigen Wrapper (einen Webdienstproxy oder den entsprechenden TransparentProxy für ES und .NET Remoting) zurückgibt, der eine bestimmte Schnittstelle implementiert. Beim Aufrufen dieser Methode können Sie angeben, welches Transportprotokoll verwendet werden soll, welche Sicherheitseinstellungen, Formatierer usw. Die verbleibende Anwendung kümmert sich nicht um das zugrunde liegende Protokoll. Dadurch können Sie eine protokollunabhängige Anwendung erstellen, sodass Sie die geeigneten Protokolle entsprechend Ihrer Anwendungsumgebung auswählen können.

Anhang D: Software- und Hardwareeinrichtung

Die folgenden Tests wurden mit drei Computern durchgeführt: einem Client, einem Anwendungsserver und einem Datenbankserver. Alle Tests wurden mit einer ausreichenden Menge an verfügbarem physischem Arbeitsspeicher durchgeführt, um unnötiges Paging zu vermeiden.

Anwendungsumgebung

• Client: Singlethread-Konsolenanwendung, geschrieben in C#, erstellt mit Visual Studio.NET 2003 im Releasemodus.
• ASP.NET Webdienst, der in IIS 6.0 unter Windows Server 2003 ausgeführt wird
• Enterprise Services-Komponenten in verschiedenen Konfigurationen (Bibliotheksaktivierung und Serveraktivierung, keine Authentifizierung und Authentifizierung auf Anrufebene), die in COM+ 1.5 unter Windows Server 2003 ausgeführt werden
• Ein eigenständiger .NET Remoting-Server als C#-Konsolenanwendung, geschrieben in C#, erstellt mit Visual Studio .NET 2003 im Releasemodus

Infrastrukturumgebung

Client:

• CPU: 2,4 GHz Intel P4
• Arbeitsspeicher: 768 MB
• O/S: Windows Server 2003 Standard Edition (mit allen Patches ab Juni 2004)
• .NET Framework 1.1 SP1

Anwendungsserver:

• CPU: 2,8 GHz Intel P4
• Arbeitsspeicher: 1024 MB
• O/S: Windows Server 2003 Standard Edition
• .NET Framework 1.1 SP1

Datenbankserver:

• CPU: 2,8 GHz Intel P4 Prescott, w/ HT, 800 MHz FSB
• Arbeitsspeicher: 1024 MB
• O/S: Windows Server 2003 Standard Edition
• Datenbank: SQL Server 2000 Enterprise Edition (mit SP3A)
• .NET Framework 1.1 SP1

Netzwerk:

• 100 MBit/s, switched Ethernet