Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

296 5 Netzwerkprogrammierung in der Praxis
148 print_srv_stats(); /* CPU-Statistik ausgeben */
149
150 unlink( PIDFILE ); /* PID-Datei entfernen */
151 exit( EXIT_SUCCESS ); /* Dummy, ... wird nie erreicht */
152 }
132–139
141–146
148–152
Der Elternprozeß schließt, nachdem er die geforderte Anzahl von Serverinstanzen
gestartet hat, den passiven Serversocket sd. Der Socket wird nicht
weiter benötigt, da sich nun ausschließlich die Kindprozesse um die Annahme
neuer Netzwerkverbindungen kümmern. Der Elternprozeß warten fortan nur
noch auf das Eintreffen eines SIGTERM-Signals, das den Server beenden soll.
Dazu greift der Dæmon in einer Schleife auf die pause()-Funktion zurück, die
den Prozeß solange unterbricht, bis ein Signal eintrifft. Im Falle des SIGTERM-
Signals verläßt das Hauptprogramm die Warteschleife
Vor dem Programmende terminiert der Dæmon zunächst seine ganzen Kindprozesse.
Er schickt dazu jeder von ihm gestarteten Serverinstanz per kill()
ein SIGTERM-Signal. Die Prozeß-IDs der Kinder wurden hierfür beim Start
im Feld child hinterlegt. Solange noch Kindprozesse aktiv sind, wartet der
Server dann in einer Schleife per wait() auf das Ende der Serverinstanzen.
Abschließend gibt der Dæmon noch die ermittelten CPU-Statistiken aus,
löscht die PID-Datei und beendet sich schließlich selbst.
5.6.4 Eigenschaften und Einsatzgebiete
Zum Abschluß vergleichen wir auch den Preforking-Server noch in unserer
Testumgebung mit den anderen Server-Varianten. Auf 30 sequentielle und
30 nebenläufige Anfragen hin muß der Server wieder Primzahlen bis zu einer
Größe von maximal 250 000 berechnen und abschließend 500 kB an Daten zum
Client transferieren.
Laufzeitmessungen
Sowohl für die sequentiellen als auch für die nebenläufigen Anfragen ist der
Preforking-Server nur geringfügig langsamer als der vergleichbare threadbasierte
Server aus Abschnitt 5.4. Wie Tabelle 5.5 zeigt, zahlt sich die Ressourcenbeschränkung
vor allem bei vielen gleichzeitigen Client-Verbindungen
sichtbar aus. Der für den Preforking-Server erforderliche Rechenaufwand
bleibt hier gerade mal um vier Clockticks hinter dem Prethreading-Server
zurück und liegt somit um nur 8% über dem CPU-Bedarf des inkrementellen
Servers (im Vergleich zu den 27% Mehraufwand des normalen prozeßbasierten
Servers aus Abschnitt 5.5).