Zur Diskussion des Datendurchsatzes muss zwischen folgenden Daten-Verbindungen unterschieden werden die WGA aufrecht erhält.

Die Verbindung zwischen WGA-Server und Browser ist die offensichtlichste Verbindung die WGA mit anderen Entitäten im Netzwerk eingeht. Ihre Durchsatzmaximierung ist jedoch nicht Bestandteil der WGA-Konfiguration, da für die Abwicklung dieses Transportes der eingesetzte J2EE-Server, bzw. ein davor verwendeter Web-Server verantwortlich ist. Dennoch kann man hier folgende Ansätze für Optimierungen formulieren die bei problematischem Performance-Verhalten  adressiert werden können:

• Verwenden sie einen HTTP-Stack der auch für den produktiven Einsatz vorgesehen ist
  Der direkte HTTP-Zugriff auf den IBM Websphere Application Server wird beispielsweise nicht für den produktiven Einsatz empfohlen sondern sollte durch einen davor geschalteten Webserver, z.B. den in der Regel mitgelieferten IBM HTTP Server, ergänzt werden. Die HTTP-Stacks der aktuellen Apache Tomcat-Versionen sind laut Dokumentation inzwischen produktivreif. Auch hier gibt es aber verschiedene Varianten und Konfigurationsmöglichkeiten die im Problemfall evaluiert werden können. Sehen sie dazu die Apache Tomcat Dokumentation unter Apache Portable Runtime . Desweiteren kann auch Apache Tomcat hinter einem dedizierten Webserver, z.B. dem Apache HTTP Server zum Einsatz kommen, auch wenn dies bei einzelnen Servern eher geringere Performance zum Resultat haben soll.
  
  
• Ist der Prozesspool ihres J2EE- und Webservers ausreichend für die Maximalanzahl gleichzeitig zu erwartender Requests?
  J2EE- und Webserver verwalten einen Pool von Einzelprozessen die für die Verarbeitung von Requests verwendet werden. Um den Server nicht zu überlasten ist hier in der Regel auch eine Maximalanzahl an Prozessen konfigurierbar (z.B. bei Tomcat das Attribut "maxThreads" an der Connector-Konfiguration in der server.xml). Die hier voreingestellte Zahl kann für die von ihnen eingesetzte Hardware, bzw. für den von ihnen erwarteten Traffic zu klein sein. Kommen mehr Requests herein als Prozesse verfügbar sind, so werden die übrigen Prozesse normalerweise in eine Warteschlange aufgenommen bin ein Prozess frei ist. Dies wirkt sich in Wartezeiten für die Benutzer ihrer Site aus.

Weniger ersichtlich, aber in den meisten Fällen von größerer Wichtigkeit, ist die Verbindung zwischen WGA-Server und Datenbank-Server.  Hier ist in allererster Linie die Natur der Verbindung entscheidend über ihre Performance, die meistens vom Typ des verwendeten Datenbank-Systems abhängt. Die langsamste Performance bieten Datenbanken auf Lotus Domino Servern, da sie über ein netzwerkfähiges, objektorientiertes Protokoll abgewickelt werden, das einen vergleichsweise hohen Overhead erzeugt.  Unter den Verbindungen zu relationalen Datenbank-Systemen finden sich effektive und weniger effektive Varianten. Folgende Faustregeln gelten:

• Betreiben sie WGA-Server und Datenbank-Server auf demselben Rechner oder verbinden sie beide mit einem hochperformanten Netzwerk
  Beide Server auf demselben Rechner zu belassen ist sicherlich netzwerktechnisch die effektivste Variante. Hier sollte jedoch bedacht werden dass die beiden Prozesse auf demselben Rechner auch um dieselben Hardware-Ressourcen konkurrieren was wiederum bremsend wirken kann. Nahezu ebenso effektiv ist es, beide auf getrennten Rechnern unterzubringen die über ein Gigabyte-Netzwerk verbunden sind.
  
  
• Für JDBC: Verwenden sie einen Verbindungs-Pool für ihre Datenbank-Verbindungen
  In J2EE-Anwendungen ist es üblich und dringend empfohlen, Datenbank-Verbindungen in einem Pool vorzuhalten um den Overhead beim Aufbau neuer Verbindungen zu minimieren (siehe Java Database Connectivity (JDBC)). Alle WGA Content Stores für JDBC benutzen einen Verbindungs-Pool, entweder einen automatischen, WGA-internen oder einen Pool des J2EE-Servers. Die Datenbank-Typen "JDBC-Database (Query only)" und "JDBC-Database with enhanced access" jedoch werden ohne Pooling eingesetzt, wenn die Verbindung zum Datenbank-Server nur über eine JDBC-URL konfiguriert wurde. Diese Konstellation sollte in Produktivumgebungen vermieden werden. Verwenden sie stattdessen einen Verbindungs-Pool ihres J2EE-Servers.
  
  
• Für JDBC: Ist der Pool an Datenbank-Verbindungen ausreichend für die Maximalanzahl gleichzeitig zu erwartender Requests?
  Ebenso wie für den Prozesspool gilt für den Verbindungspool, dass jeder einzelne Request eine Verbindung pro involvierter Datenbank benötigt. Die Maximalanzahl an Verbindungen in ihrem Pool limitiert also die Maximalanzahl gleichzeitig verarbeitbarer Requests. Den WGA-internen Verbindungspool konfigurieren sie über Datenbank-Optionen (siehe Konfiguration des WGA-internen Connection Pools). Er verfügt standardmäßig über maximal 100 gleichzeitige Verbindungen.
  
  
• Für JDBC: Prüfen sie die verfügbaren Verbindungsvarianten ihres Datenbank-Treibers
  JDBC-Treiber sind in verschiedenen Typen verfügbar, welche unterschiedliche Ansätze verfolgen. Ein "Typ 4"-Treiber beispielsweise ist eine pure Java-Implementierung des Verbindungsprotokolls, was langsamer sein kann als ein "Typ 2"-Treiber, der native Komponenten beinhalten kann. Beachten sie hierbei allerdings auch die Empfehlungen in diesem Handbuch zu ihrer eingesetzten Datenbank-Plattform. Nicht alle Treiber sind mit WGA einsetzbar.
  
  
• Für JDBC: Prüfen sie die verfügbaren Konfigurations-Optionen ihres Datenbank-Treibers
  JDBC-Treiber verfügen in der Regel über eine Vielzahl von Konfigurations-Optionen, welche das Verhalten des Treibers feinoptimieren. Diese sollten in der Dokumentation des Treibers einsehbar sein.
  
  
• Für Domino: Konfigurieren sie den Domino CORBA Connection Pool
  Ebenso wie für JDBC beinhaltet WGA einen internen Connection Pool für CORBA-Verbindungen zu Lotus Domino. Auch hier können einige Konfigurationsoptionen gesetzt werden welche die Performance beeinflussen. Diese werden jedoch global als Java-Systemvariablen angelegt und sind in deren Referenz am Präfix "de.innovationgate.wga.domino" erkennbar. In der Regel ist die Anzahl an CORBA-Verbindungen entscheidend deren Konfiguration hier beschrieben wird: Anpassen der Domino-Verbindung auf hohe Belastungen