Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

264 5 Netzwerkprogrammierung in der Praxis
verbraucht wurden und berücksichtigt dabei sogar den CPU-Verbrauch aller
Nachfahren, also auch aller Kind- und Kindeskindprozesse, was uns später bei
den Serverimplementierungen mit mehreren Prozessen sehr gelegen kommt.
Da wir lediglich an einer Gesamtzeit interessiert sind, addieren wir die Zeitdifferenzen
der User- und Systemzeiten aller Prozesse.
5.2.4 Eigenschaften und Einsatzgebiete
Wir testen den iterativen Server nun mit dem in Abschnitt 5.1 entwickelten
Clientprogramm. Als Serversystem kommt ein älterer IBM RS/6000 Server,
Modell 270, mit zwei Power3-CPUs (je 375 MHz) und Betriebssystem AIX 5.3
zum Einsatz. Der Test-Client läuft auf einem handelsüblichen PC mit Debian-
Linux 3.1, der mit 3,0 GHz schnell genug ist, um den Server mit Anfragen zu
sättigen. Die beiden Systeme befinden sich im selben Subnetz und sind über
einen Switch mit 100 Mb/s miteinander verbunden. Die Gesamtlaufzeit des
Clients wird mit dem Unix-Systemkommando time gemessen.
Laufzeitmessungen
In einem Testlauf stellt der Client insgsamt 30 Anfragen an den Server, wobei
das Sieb des Eratosthenes Primzahlen bis zu einer Größe von maximal
250 000 berechnen und der Server abschließend 500 kB an Daten zum Client
transferieren muß. Die 30 Anfragen werden einmal sequentiell (1 Thread
stellt nacheinander 30 Anfragen) und einmal nebenläufig (30 Threads stellen
nebenläufig je eine Anfrage) an den Server gestellt.
Tabelle 5.1. Laufzeitmessungen für den iterativen Server
Laufzeit Client CPU-Zeit Server
30 Anfragen, sequentiell 10,84 s 910 Clockticks
30 Anfragen, nebenläufig 10,54 s 909 Clockticks
Die in Tabelle 5.1 zusammengestellten Laufzeitmessungen zeigen, daß serverseitig
in beiden Fällen die gleiche CPU-Zeit zur Beantwortung der Client-
Anfrage benötigt wurde. Dies ist nicht weiter überraschend, da der Server die
30 Anfragen in jedem Fall, d. h. insbesondere unabhängig vom Client, sequentiell
beantwortet. Aus Sicht des Clients ist die Gesamtlaufzeit des nebenläufigen
Clients dabei nur geringfügig kürzer als die des sequentiellen Clients. Der
iterative Server kann offensichtlich keinen Vorteil aus dem vorhandenen zweiten
Prozessor schlagen. Der marginale Zeitvorteil läßt sich folgendermaßen
begründen: Stellt der Client nacheinander 30 einzelne Anfragen, ergibt sich