Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

117 exit( EXIT_FAILURE );
118 }
5.5 Nebenläufige Server mit mehreren Prozessen 287
119
120 /* Prozeß in einen Daemon umwandeln */
121 daemon_init( argv[0], PIDFILE , LOG_DAEMON );
122
123 init_srv_stats(); /* CPU-Statistik initialisieren */
124
125 accept_handler( sd ); /* Accept -Handler aufrufen */
126
127 /* Falls die Schleife durch SIGTERM beendet wurde */
128 print_srv_stats(); /* CPU-Statistik ausgeben */
129
130 unlink( PIDFILE ); /* PID-Datei entfernen */
131 exit( EXIT_SUCCESS ); /* Daemon beenden */
132 }
120–125
Bevor der Aufruf des Accept-Handlers die Verarbeitung der eingehenden Netzwerkverbindungen
startet, werden noch die CPU-Statistiken initialisiert und
der Serverprozeß wird in einen Dæmonprozeß umgewandelt.
Sobald dem Prozeß ein SIGTERM zugestellt wurde, hat daemon_exit den
Wert 1 und die accept_handler()-Funktion kehrt folglich zurück. Das Hauptprogramm
gibt dann die verbrauchte CPU-Zeit aus, löscht die PID-Datei und
beendet den Dæmon schließlich.
5.5.4 Eigenschaften und Einsatzgebiete
Natürlich wollen wir auch den prozeßbasierten nebenläufigen Server in der
schon gewohnten Testumgebung (vgl. Abschnitt 5.2.4) untersuchen. Wieder
strapazieren wir den Server dazu mit 30 sequentiellen und 30 parallelen Anfragen
und vergleichen die Messungen mit den bisher erzielten Meßergebnissen.
Laufzeitmessungen
Im direkten Vergleich mit der threadbasierten Variante aus Abschnitt 5.3 gibt
sich die Version mit mehreren Prozessen nur geringfügig behäbiger. Auch hier
zeigt sich jedoch, daß im Falle vieler gleichzeitiger Anfragen der Mehraufwand
gegenüber dem iterativen Server deutlich ansteigt. Mit einem CPU-Aufwand
von 1157 Clockticks liegt der Mehrprozeß-Server bei 30 parallelen Anfragen
immerhin um rund 27% über dem Meßergebnis für den iterativen Server. Hier
macht sich der deutlich erhöhte Scheduling-Aufwand für 30 Prozesse bei nur
zwei Prozessoren bemerkbar.