Re: OpenBSD

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Mon, 27 Oct 2003 02:39:24 +0100

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

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

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.

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.

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

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

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

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

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

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

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

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

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

-- 
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 - 02:40:29 CET

search this site