Reduzierung von Netzlast durch den Einsatz von ActiveX

Leserbewertung (0): bewerten... kommentieren...

• In einem Netzwerk müssen regelmäßig ASCII-Daten gelesen, konvertiert und danach in verschiedene Tabellen des SQL-Servers abgelegt werden.
• Ausgelöst wird der Datenimport durch einen Anwender, der regelmäßig über den Fortschritt des Import-Vorgangs informiert werden will.
• Die ASCII-Daten stehen in einem Verzeichnis auf dem Server.
  Auf dem Server läuft der SQL-Server, der Zugriff erfolgt über ADO
  Es stehen ein "normaler" Anwender PC (64 MB) und ein High-Performance Server (128 MB oder mehr) zur Verfügung.

Lösungen

1. Die Standard-Lösung, die auch als FAT-Client bekannt ist, ist eine einzelne Standard-Exe, die die ASCII-Daten vom Server liest, konvertiert, zwischendurch die Anwender-Anzeige aktualisiert und dann über ADO dem SQL-Server die Daten zuführt. Das Netzwerk wird zweifach belastet, zum Einen durch das periodische Lesen der ASCII-Daten, zum Anderen durch "Schreiben" der ADO-Daten zum SQL-Server. Der Client wird sämtliche Systemressourcen vereinnahmen, ein weiteres Arbeiten mit diesem PC ist nicht empfehlenswert.
   
   
   
    
2. Seit der Visual Basic Version 4 stehen uns durch dieses Werkzeug Mechanismen zur Verfügung, die wir nutzen können. Der Import- und Konvertierungs-Code wird als ActiveX-Server ausgelagert. Im Client, wird nur einmalig angezeigt, ob und welche ASCII-Daten vorliegen. Der VB-Client startet dann den ActiveX Import-Server, der dann über das Netzwerk die ASCII-Daten liest, konvertiert und über ADO dem SQL-Server zuführt. Als vorbereitende Maßnahmen erhält der VB-Client eine zusätzliche Klasse, über die dann Die Fortschrittsanzeige gesteuert wird. In Sachen Netzwerkverkehr hat sich nichts geändert, nur bei den Systemressourcen hat sich eine Verschiebung ergeben. Die gesamte Rechenleistung wird nun vom Import-Server in Beschlag genommen. Der Client hat außer der Auswahl und der Anzeige nichts zu tun.
   
   
   
    
3. Nachdem die Lösung 2 getestet, kann der ActiveX Import-Server auf den Server-PC verlagert werden. Der Code ist mit der Lösung 2 identisch. Über RPC (Remote Procedure Calls) oder über DCOM werden jetzt Daten ausgetauscht. Da es sich bei diesem Austausch aber um relative wenige Informationen handelt, müssen Sie entscheiden, ob Sie die etwas kompliziertere Einstellung der Rechte eines "asynchronen" Importservers mit Callbackfunktionen vornehmen und mit DCOM arbeiten wollen, oder aber mit dem Subset von DCOM, nämlich RPC
   
   Wir wir sehen, wird über den Thin-Client nur noch die Informationen, ob und welche ASCII-Daten vorliegen, ermittelt. Das Starten des Importservers wird über "Create..." vorgenommen.
   
   Set objServer = CreateObject (stClassname)
   
   Nach erfolgreicher Initialisierung des Servers wird die Empfangsklasse instanziert und dann über eine Methode des Servers diesem übergeben.
   
   objServer.AddObjReference objReference
   
   Diese Referenz gibt dem Importserver die Möglichkeit, den Fortschritt des Imports an den Client zurückzumelden. Denn bei der Übergabe der ausgewählten Clientdaten an den Server wird ja nicht in dieser Prozedur des Servers verweilt, sondern zuerst die übergebenen Informationen im Server gespeichert, anschließend ein Timer gestartet und dann sofort zum Aufrufer zurückgekehrt. Über diesen Kanal können wir also keine weiteren Informationen austauschen.
   
   Durch die oben beschrieben Übergabe der Objektreferenz unserer clsInfo hat der Server nunmehr die Möglichkeit, Daten an den Client zu übergeben. Dabei wird der Server jetzt zum Client und der Client zum Server. Wenn Sie DCOM benutzen müssen Sie die Empfangsklasse clsInfo unseres Clients als Server mit den Rechten versehen, auch bei RPC muß die Auswahl "Remote Activation" aktiviert sein.
   
   Der im Server gestartete Timer aktiviert nun den Importprozess und aktualisiert über eine geeignete Methode im Client dessen visuelle Anzeige
   
   
   
   Betrachten wir jetzt die Netzwerklast. Zuerst wird die Auswahl der zu importierenden ASCII-Daten gelesen und im Client dargestellt. Nach der Auswahl erfolgt die Instanzzierung des Servers. Nach erfolgreicher Instanzzierung und Weitergabe des Empfangsklassen-Objekts wird dem Server nur die Auswahl der ASCII-Daten übergeben. Da der Importserver auf dem Server installiert ist, auf dem sich sowohl ASCII-Daten als auch SQL-Server befinden, wird fast kein Netzverkehr erzeugt. Lediglich die Informationen des Importfortschritts, die an den Client zurückgemeldet werden (Callback), erzeugen minimalen Netzverkehr.
   
   Es sind aber noch weitere Vorteile zu erkennen. Da wir den Client vom Server "entkoppelt haben", müssen wir natürlich durch geeignete Methoden ein vorzeitiges Beenden des Clientprogramms verhindern. Weitere Methoden im Clientprogramm können jedoch ausgeführt werden, es werden fast keine Systemressourcen benötigt. Da wir auch keine Datenzugriffsmethoden im Client benötigen, müssen diese auch nicht installiert werden. Es wird somit auch weniger Hauptspeicher vorausgesetzt. Da der Importprozess jetzt auf dem Server lokal läuft, sind die Geschwindigkeits- vorteile sofort ersichtlich. Bei einem Kunden hatten wir die Lösung 1 implementiert. Der Importvorgang dauerte 30 Minuten. Durch den Einsatz des Importservers nach Lösung 3 konnte der Vorgang auf 5 Minuten verkürzt werden.