Re: OpenBSD

Bernd Walter wrote:
> On Mon, Oct 27, 2003 at 12:37:56AM +0000, Jens Rehsack wrote:
>
>>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:
>>>
>>>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.
>
> Nein - du hast Overhead.
> Parallel kann auf einem 1 CPU System überhaupt nichts laufen.
> Soweit die verkürzte Aussage.

Aber ein moderner PC ist kein 1 Prozessor System mehr. Es
sind zwar nicht alles die gleichen CPU's, aber parallel arbeiten
können sie trotzdem.

> Natürlich hast du IO, worauf du warten musst, aber dann nimmst du
> dich einer anderen Sache an - soweit kein Unterschied zum Thread.
> Allerdings kannst du die andere Sache übernehmen, ohne den Overhead
> eines Thread Wechsels.

Richtig, asynchron arbeiten geht auch wunderbar.

> Ganz gemeine Geschichte mit der Performance ist, daß sowas Ineffzientes
> wie Java Servlets in der Regel damit keine Probleme haben - die machen
> einfach dynamischen Content und verteilen sich.
> Der Punkt ist, daß dort Wert auf Portierung und Performance gelegt
> wird, womit man sich die Performancesteigerung durch einen großzügigen
> Rechnerpool nicht verscherzen will.
> Für einen einzelnen User nicht schnell, aber bei vielen Usern kaum
> langsammer, wenn man die Möglichkeiten nutzt.
> Der Punkt ist absolut nicht, ob dynamisch oder statisch, sondern eine
> vernünftige Datenverwaltung.

Ich habe etwas ähnliches zu tun.

> Du hast globale Daten mit geringem Aktualitätsbedarf, z.B. Produkte in
> einem Shop.
> Hier kannst du eine zyklisch verteilte read-only Datenbank verwenden,
> welche du problemlos skalieren kannst.
> Dann hast du globale Daten mit Aktualitätsbedarf, wie z.B. Kundendaten,
> welche auch per Web aktualisiert werden können.
> Hierfür musst du eine zentrale Datenbank verwenden, oder eine welche
> derartiges verteilt behandeln kann - letzteres ist teuer aber Updates
> auf derartige Daten sind selten und deshalb kaum ein echtes Problem.
> Dann hast du Session bezogene Daten, wie z.B. einen Warenkorb.
> Letzteren kannst du problemlos als komplette Session zwischen den
> Prozessen/Servern hin und herschieben, weil ein derartiger Wechsel
> durch äußere Maßnahmen, wie z.B. einen entsprechenden Load-Balancer
> nahezu kaum vorkommen.
>
> Was ich sagen will ist, daß der für die Aufgabe notwendige
> Kommunikationsaufwand gering ist - wenn er höher liegt, dann weil
> die Aufgabe schlecht umgesetzt wurde.

Schon klar.

>>>>>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?
>
>
> Ein Webserver ist nichts weiter als ein Arbeitssklave - dazu gehört für
> große Systeme immer noch Beiwerk um die Dinger zu kontrollieren.

Und für mich dreht sich's um's Beiwerk.

>>>Ist ja eh nicht viel, was du normalerweise brauchst.
>>
>>Sorry, aber das ist wohl stark anwendungsspezifisch.
>
> Kaum.

>>>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.
>
> Auch die können das - teilweise sogar besser als einem lieb ist, weil
> die nach Aussagen von dieser Liste gar den nächsten Connect auf die
> gleiche IP machen, aber dafür gibt es Load-Balancer.

Stimmt auch wieder. Aber das meinte ich gar nicht.

>>>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.
>
> Mit Windows kann ich auch eine gute Systemauslastung erzielen.
> Nur Auslastung ist nicht Ausnutzung.
> Threads sind kein Allheilmittel - es gibt Lösungen schon viel länger,
> da es auch die Probleme schon viel länger gibt.
> Threads sind nur ein Weg das ohne viel Hintergrundwissen und manchmal
> auch bequemer hinzubekommen.
> Leider führen Threads derart schnell zum Ziel, daß etliche
> Programmierer dann selbst dazu zu wenig wissen.

Das muss ich jetzt aber von mir weisen. Ich habe sicher nicht
Deine Erfahrung. Ich weiss, das Threads kein Allheilmittel sind.
Wie schon erwähnt, ich habe auch Projekte ohne Threads mit guter
Systemauslastung entwickelt.

>>Ist halt immer die Frage, wie gut das Design ist.
>
> Weniger - es ist eine Frage ob du den Unterschied brauchst.
> Wie schon erwähnt bist du mit dem Webserver in einem Bereich, den du
> bei einem sauberen Seitendesign auf mehreren Maschinen verteilen kannst.
> Du hast damit immer die Performance die du brauchst - egal ob mit
> Threads oder anders und auch egal, ob mit C oder Java und auch egal
> ob OpenBSD oder FreeBSD.

Bestreite ich doch gar nicht.

>>>>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)
>
> Quatsch Interprozess mit shared Memory geht absolut nicht durch den
> Kernel - ist doch so oder so der gleiche Speicher.
> Was anderes passiert mit Threads auch nicht.
> Wie schon gesagt - 100% identisch.

Shared Memory ja. Bei Semaphoren gibt es die Unterschiede.
Und schreibender Zugriff auf Shared Memory muss über
Semaphoren gesteuert werden.
Shared Memory würde ich allerdings immer, egal ob
für Threads oder mehrere Prozesse, über IPC beschaffen,
denn dann ist er im Zweifel noch da, wenn der Prozess
abraucht. Kann schonmal nützlich sein.

>>>>>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.
>
> Genau deshalb ist das schnurz egal - du nimmst soviele Maschinen, wie
> du dafür brauchst, damit es ausreichend schnell ist.
> Die veränderlichen Daten sind dein Skalierungsproblem und die gilt es
> Sinnvoll zu behandeln.

Jein. Bei meinem aktuellen Problem werden oft Seitenergebnisse
live berechnet. Die Quellen sind hierbei nicht mein Problem,
sondern die Ergebnisse. Das lässt sich mit mehreren Prozessen
oder mit Threads und mehreren Prozessen lösen.
Und ich tendiere dazu, die zweite Variante zu wählen. Damit
kann ich auf mehrere Maschinen skalieren oder auf einer
Maschine - wie es beliebt.

>>>>>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.
>
> Dann lese das noch mal.

Das hatte ich nach der Diskussion eh' vor.

>>>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.
>
> Ich erinnere mich an einen Insider Trick eines Windows Admins.
> Man starte zwei IIS auf dem System - wenn einer crashed, dann geht
> es noch weiter.
> Zu der Zeit hatte er gar recht mit der Vorgehensweise, weil das Dingen
> echt nicht stabil lief - wohl die vielen schludrig geschriebenen isapi
> Dinger schuld...

:-)
Ausfallsicherheit ist dann auch noch da, das bekommst Du aber
auch mit Watcher-Prozessen hin. Dann sogar über Maschinengrenzen
hinweg, wenn Du magst.

>>>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.
>
> Gegenüber select und Co sicherlich einfacher zu behandeln.
> Gegenüber getrennten Prozessen immerhin noch ein wenig einfacher zu
> behandeln.
> Aber letzlich die vom Potential her ineffzienteste Variante.

Na, na - heisst ja nicht, dass ich select und Co nicht
trotzdem verwende. Ich kann Deine Einwände ja verstehen,
ich habe schon viele Programme gesehen, die sinnlos Threads
verwendet haben. Aber Threads sind nicht per default
schlecht, sondern - wie alle anderen Werkzeuge auch - im
Falle des Falles mal so, mal so.

>>>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.
>
> Ich setze normalerweise auch auf den Apache, weils bequemer und
> flexibler ist.
> Wohlwissend, das etwas anderes schneller wäre.
> Schließlich kann ich immer noch Maschinen dazustellen, wenns doch
> mal eilt.

Mir geht es ja gar nicht um Apache oder nicht Apache, oder
FreeBSD oder OpenBSD. Ich wollte ja nur die Vorteile und
Nachteile der jeweiligen Lösungen aus Erfahrungsberichten
hören. Und das kam ja auch.

Und noch ein bisschen was über IPC zum Denken und nochmal
lesen bekommen. Gute Ausbeute für einen Sonntag Abend :-)

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 - 03:29:37 CET