Re: OpenBSD

Bernd Walter wrote:
> 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.

Laut Stevens schon. Bei BSD bin ich jetzt nicht sicher (lange nichts
mehr mit Threads gemacht), allerdings waren die Thread-Geschichten
mehr Userland Implementierungen und die IPC-Geschichten mehr im Kernel.

> Zum einen gibt es Shared Memory auf zwischen Prozessen und zum anderen
> haben die Dinger eh nichts miteinander zu komunizieren.

Für statische Webseiten: Ja. Dynamische: Nein.

> 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.

:-)
Philosophiefrage. Du kannst den connect() auch im Hauptthread
annehmen und dann passiert Prozessintern dasselbe, was Du für
mehrere Prozesse beschreibst. Der erste Thread greift sich das
Ding und die anderen haben nichts damit zu tun.

>>>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.

Außer, Du kannst Aufgaben in Deinem Prozess parallelisieren
(File-I/O, Datenbank-I/O, Netzwerk-I/O, Berechnungen).
Dann wäre es effizienter.

> Und den zweite (dritten, etc) Prozess für die restlichen CPUs brauchst
> du nur einmal zu starten.

Schon klar.

>>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.

Statisch: Ja. Dynamisch: Nein.
Ist 'ne Frage, wie weit die dynamische Berechnung
in den Webserver integriert ist. Hatten wir schon,
und für den Fall, sie ist es nicht, hast Du Recht.
Damit ist aber nur das Problem verschoben und nicht
gelöst.

>>>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.

??? Wie jetzt? Extern?

> Ist ja eh nicht viel, was du normalerweise brauchst.

Sorry, aber das ist wohl stark anwendungsspezifisch.

> 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.

Na ja, was im Web so an Clients rumgeistert und dann von anständig
zu sprechen? 80% nutzen MSIE.

> 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.

Da habe ich mich wohl unklar ausgedrückt. Das Design auf Threads
aufzusetzen, heisst nicht, nicht auch mehrere Prozesse zulassen
zu wollen oder zu können. Nur lassen sich durch M:N Threadabbildungen
deutlich bessere Systemauslastungen hinbekommen.

Ist halt immer die Frage, wie gut das Design ist.

>>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.

Doch, Intra-Prozess ist Userland, Interprocess muss durch den Kernel.
Das dauert etwas länger, vor allem auf x86 (da war's wieder)

>>>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.

Eben recht selten. Oftmals sind z.B. die Produktbeschreibungen
konstant und die am häufigsten abgerufenen 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.

???
Ich hab' den Stevens II (IPC) jetzt im Büro, aber IMHO ist es
das eben nicht.

> 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.

Ja, allerdings trifft das nur zu, wenn man nicht ordentlich
programmiert :-)
Ich für meinen Teil mag Lint - segfaults in der Produktion
habe ich eigendlich recht selten.

> Wie dem auch sei - ich kenne deinen konkreten Fall nicht und kann
> den nicht im speziellen bewerten.

Ich habe mich ja auch noch gar nicht entschieden. Ich denke
nur drüber nach, wie's am besten passen könnte. Und mit KSE
gibt's unter FreeBSD dann auch eine gute Thread-Bibliothek,
die Kernel- und Userland Threads kann (IIRC).
Threads haben für mich den Vorteil, dass getrennte Stack-Frames
vorliegen.

> Es mag durchaus sein, daß es für deinen Fall einfach der beste Weg war.

In einigen früheren Projekten ja. In anderen nein. Da hab' ich dann
auch keine Threads genommen :-)

> Will ja auch keinem einen Vorwurf machen - nur aufklären.

Ich versteh' schon. Ich kenne auch die Nachteile von Threads.
Aber eben auch die von IPC. Und auch von beiden die Vorteile.
Ich muss mich dann eh' mal hinsetzen, wenn's soweit ist, und
vorher mal ein paar Benchmarks runterschreiben, um zu sehen,
was für den Fall dann das Beste sein wird.

Gruß,
Jens

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:38:39 CET