Re: OpenBSD

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Mon, 27 Oct 2003 00:59:32 +0100

On Sun, Oct 26, 2003 at 10:06:40PM +0000, Jens Rehsack wrote:
> Bernd Walter wrote:
> >On Sun, Oct 26, 2003 at 06:42:37PM +0000, Jens Rehsack wrote:
> >>>thttpd hat ebenfalls nichts von SMP, kann aber richtig eingesetzt
> >>
> >>Schade, eigendlich.
> >
> >Warum?
> >SMP ist erst mal eine Bremse, genauso Threads.
>
> Weil der Kommunikationsaufwand zwischen Threads geringer ist, als
> der zwischen Prozessen. Selbst wenn immer ein Thread eine Aufgabe
> bearbeitet, ist das letztendlich effizienter, als eine Aufgabe
> pro Prozess.

Das der Komunikationsaufwand geringer ist halte ich für ein Gerücht.
Zum einen gibt es Shared Memory auf zwischen Prozessen und zum anderen
haben die Dinger eh nichts miteinander zu komunizieren.
Mache einfach mehrere Prozesse mit einem listen() auf den gleichen Port
und es kümmert sich der Prozess darum, der als erstes den Connect
annimt.
Die Tatsache, daß man derart unabhängige Aktionen in einen gemeinsammen
Prozess stopft schaft erst die Abhängigkeit.

> >Der Verlust muss erst mal wieder kompensiert werden.
>
> Wird er auch, wenn der Programmierer Ahnung davon hat :-)
> Ich weiss, Unix' Hammer ist fork(), aber ich komme letztendlich
> aus der OS/2-Welt, und da waren Threads gar nicht so schlecht.

fork brauchst du nur, wenn du einen neuen Prozess aufmachen willst.
Mit der kevent/select/poll Variante brauchst du das aber nicht.
Und den zweite (dritten, etc) Prozess für die restlichen CPUs brauchst
du nur einmal zu starten.

> Vor allem gab's sie schon immer und daher hatte ich die Gelegenheit,
> das von Anfang an so zu lernen :-)
>
> Unter Unix ist das inzwischen auch richtig gut. Thread-Pool,
> Task -> Thread Zuordnung, eine Aufgabe pro Task, fertig ist der Lack.
> Kommunizieren kannst Du über pthread_mutex statt sysvsem, ist auch
> etwas fixer.

Wenn du komunizieren musst - den Bedarf sehe ich bei einem Webserver
nicht.

> >Und ein Webserver soll erst mal TCP Requests abhandeln - problemlos
> >auf mehrere Maschinen/Prozesse verteilbar.
>
> Außer, er kann nicht mehr nur statische Seiten liefern. Dann kommt
> es darauf an, wo die Abarbeitung erfolgt. Im Webserver (Modul), dann
> ist Multiprozess nicht wirklich erste Wahl. Machst Du's extern, z.B.
> via FastCGI, dann kann der Webserver natürlich soviele Prozesse haben,
> wie er will.

Weder noch - sowas verwaltest du extern.
Ist ja eh nicht viel, was du normalerweise brauchst.
Datenbankzugriff fürs normale und ein gecachter Sessionhandle, den
man sich im Falle eines Falles schnell mal rüberschieben kann, aber
selbst das ist kaum erforderlich, da ein anständiger Client einen
Connection Cache hat und den Prozess nur selten wechselt.
Natürlich kannst du deinen Webserver auch so designen, daß dieser auf
einen einzigen Prozess angewiesen ist, dann ist aber deiner Skalierung
durch die Designwahl eine enge Grenze gesetzt - nämlich maximal ein
Rechner.

> Prozessinterne Kommunikation ist immer schneller als Interprozess-
> kommunikation. Wenn allein die Konfiguration lesen und in
> Datenstrukturen umsetzen knapp 5% der Laufzeit eines Durchlaufs
> ausmacht, ist es besser den einfach wegzulassen, wenn man z.B.
> das nur 1x beim Prozessstart erledigt und jeder Thread lesend
> darauf zugreift.

Wenn du zwischen 2 Threads Daten austauschst, dann musst du
Syncronisieren (Mutex oder ähnl.), sonst wird das nichts.
Exakt das gleiche passiert bei der Interprozesskomunikation per shared
memory - Fazit: kein Unterschied.

> >Die dahinterliegende Datenbank ist das, was man nicht mehr so einfach
> >verteilen kann.
>
> Kommt auch immer drauf an. Typischerweise sind bei Onlineshops
> ein sehr hoher Prozentsatz rein lesende Zugriffe. Da reicht ein
> Datenbakserver mit Lesezugriff völlig hin, den man beliebig
> verteilen (theoretisch) kann.

Ja sicher - es geht dabei um veränderliche Daten.

> >Wenn du tatsächlich eine 2 CPU Maschine im Frontend hast, dann startest
> >du halt zwei Instanzen und das wars - ohne Thread Overhead.
>
> Aber mit IPC Overhead - der mich im Zweifel teurer kommt.

Wenn man es falsch macht - ja.
Wie oben schon erwähnt - shared memory ist absolut identisch zur
Komunikation zwischen Threads.
Da es aber getrennte Prozesse sind hat man keine zusätzlichen Abhängig-
keiten geschaffen.
Man hat sogar etliche Vorteile - ein Segfault betrifft nicht alles.
Und man hat in jedem Prozess einen getrennten Adressraum für lokale
Daten.

Wie dem auch sei - ich kenne deinen konkreten Fall nicht und kann
den nicht im speziellen bewerten.
Es mag durchaus sein, daß es für deinen Fall einfach der beste Weg war.
Will ja auch keinem einen Vorwurf machen - nur aufklären.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 27 Oct 2003 - 01:00:09 CET

search this site