Frage Webserver und Threads

[Occasus]

Hallo.
Ein Webserver kann ja Gebrauch von Threads, um parallel
mehrere Anfragen zu bearbeiten. Gibt es auch Beispiele fur Anwendungen, bei denen es besser wäre, nur
einen einzelnen Thread (d.h. einen normalen Prozess) zu verwenden? Wenn ja, wie sähe so eine Anwendung aus und wenn nein, wieso nicht?

Vielen Dank im vorraus.

 

[Yuuri]

Da kannst du dich in mod_php und Fast CGI einlesen. Kommt auf genau deine Frage hinaus.

 

[PrOOnOOb]

Ja z.B bei Java wen du ein Bild in Schwarz weis Konvertierst Machst du diese Funktion nicht in einen Separaten Thread Hängt das ganze Programm während des Konvertierens.

 

[SoDaTierchen]

Ist das jetzt eine generelle Frage, oder eine Frage speziell für Webserver?

Generell lohnen Threads nur, wenn du Aufgaben auch parallel ausführen kannst. Threads erzeugen und verwalten erzeugt etwas Overhead, nicht viel, aber spürbar. Wenn du aber jetzt ein Programm hast, was stets und ständig auf Nutzereingaben wartet, wäre es ja blödsinn das Programm weiterlaufen zu lassen, obwohl der Nutzer noch nichts gedrückt hat - hier wären Threads überflüssig, bzw. würden falsch programmiert sogar Unfug machen.

stell dir nen internetspiel vor, bei dem viele nutzer nen button drücken müssen, wenn es leuchtet. jetzt drücken a und b fast zeitgleich und das signal kommt fast zeitgleich an.
unthreaded: das erste signal gewinnt.
threaded: das erste VERARBEITETE signal gewinnt. wenn also ein signal in einen thread rutscht, der danach aber von einem anderen task unterbrochen wird, gewinnt der, der später dran war. ist zwar nicht sooo dramatisch, aber ein beispiel, wo threads nicht gut sind.

 

[Occasus]

es geht ja bei der frage darum wo mehrere threads nicht gut sind und nicht wann sie allgemein nicht gut sind

 

[SoDaTierchen]

Ich ERAHNE mal, du meintest die Bedeutung von Threads speziell bei Webservern - unterschiedet sich nicht groß von normalen PCs, nur dass du bedenken musst, dass meist nur eine geteilte Netzwerkkarte vorhanden ist.

Ansonsten verweise ich auf die Schlagworte von Yuuri und Google

 

[DHundt]

Mahlzeit,

wie SoDaTierchen schon schrieb:
Kannst du Dinge unabhängig voneinander parallel bearbeiten (z.B. eine Website an mehrere Clients ausliefern), dann sind Threads das richtige Mittel.
Bist du darauf angewiesen, dass Dinge nacheinander bearbeitet werden (z.B. erst Login prüfen, dann Website ausliefern), dann kann dies nur innerhalb eines Threads bzw. Prozesses passieren. Ein aufsplitten auf 2 Threads wäre unnötig, da der zweite erst auf das Ergebnis des ersten warten muss und danach nicht mehr benötigt wird.

Außerdem kann es bei Multithreading zu Problemen mit gleichzeitig ablaufenden Tätigkeiten kommen (z.B. Datei schreiben).
Beispiel: Kunde1 und Kunde2 kaufen gleichzeitig Artikel A, von dem nur noch 1 Stück verfügbar ist. Wird nicht "synchronisiert", so bekommen beide eine Bestellbestätigung.

Da mehrere Threads auch mehr Verwaltungsaufwand bedeuten (Speicher, Prozessorzeit) kann es unter Umständen auch kontraproduktiv sein.
Beispiel: DoS (darum wird die Anzahl der Threads auch begrenzt)
oder bei Bildbearbeitung pro Pixel (x Mio. gleichzeitige Threads sind langsamer als 10 gleichzeitige Threads)

Wie gesagt, es lässt sich leider nur erahnen, auf was deine Frage genau abzielt.

Gruß

 

[Occasus]

pefekte antwort =) vielen dank

 

[Daaron]

Wichtiger Aspekt bei Webservern, speziell Apache2:
- mod_php und suPHP sind nicht threadsicher. apache_mpm_prefork unterstützt deshalb keine Threads
- fastcgi und fcgid unterstützen multithreading genauso wie multiprocessing
- Besucher fordert 4 Daten an: große komplexe Grafik, die von einem PHP-Script aufwändig berechnet wird, kleines HTML-File, kleines CSS und ne kleine Sprite... ohne Threading und Multiprocessing müsste der Client jetzt warten, bis der Server alles nacheinander berechnet hat. Mit paralleler Ausführung kriegt der Client zumindest die HTML, die Sprite und die CSS-File quasi instant, nur das PHP-Script-Bild dauert lange

Viele Apache-mpm's unterstützen nur Multiprocessing, die wenigsten Threading. Parallelisieren kann beides, effektiv ist beides, aber einen Prozess zu forken dauert länger, als einen Thread zu eröffnen.

 

[carom]

es geht ja bei der frage darum wo mehrere threads nicht gut sind und nicht wann sie allgemein nicht gut sind

Etwas schwierig, die Intention deiner Frage zu verstehen. Mehrere Threads sind nie gut, wenn du sie nicht brauchst. Es gibt Szenarien, da brauchst du zwingend mehr als einen Thread (weil zum Beispiel andererseits dein User-Interface blockieren würde) und es gibt Szenarien, da bringen mehrere Threads Vorteile, sind aber keine technische Notwendigkeit wie beim ersten Fall - beispielsweise Aufgaben, die sich zu Gunsten der Ausführungsgeschwindigkeit nebenläufig (nicht zwingend parallel) abarbeiten lassen. Multithreading ist also kein cooles Feature, dass du unbedingt in dein Programm einbauen musst, sondern du sollst es dann einbauen, wenn es Sinn macht und von deinen Anforderungen verlangt wird. Nebenläufige Programme sind oft sehr schwer zu debuggen und legen scheinbar nicht deterministisches Verhalten an den Tag (im Sinne von nicht reproduzierbar), das erfordert etwas Übung. Race conditions, Deadlocks und Starving sind beliebte Fehlerquellen beim Einsatz mehrerer Threads, kannst ja mal Google anwerfen.

Wenn deine Frage eher auf Webserver abzielt: es gibt Ansätze, da brauchst du nicht zwingend für jeden Request einen eigenen Thread. Mit Technologien wie node.js oder Vert.x kannst du Webserver realisieren, die eine große Anzahl an Requests sequentiell in einem oder ein paar wenigen Threads abarbeiten. Hier musst du jedoch aufpassen, dass deine Programmlogik den Thread nicht unnötig lange blockiert, da sonst alle anderen Nutzer in die Röhre schauen. Ansonsten musst du die kritischen Teile Auslagern und deren Antworten dann über Callbacks entgegennehmen, in der Zwischenzeit bist du für neue Requests frei.