{"id":35106,"date":"2019-10-31T22:02:22","date_gmt":"2019-10-31T19:02:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/proizvoditelnost-setevyh-prilozhenij-linux-vvedenie\/"},"modified":"2019-10-31T22:02:22","modified_gmt":"2019-10-31T19:02:22","slug":"proizvoditelnost-setevyh-prilozhenij-linux-vvedenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/proizvoditelnost-setevyh-prilozhenij-linux-vvedenie","title":{"rendered":"Die Leistung von Netzwerk-Anwendungen unter Linux. Einleitung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Webanwendungen werden heute \u00fcberall eingesetzt, und HTTP macht dabei den L\u00f6wenanteil unter allen Transportprotokollen aus. Bei der Untersuchung der Nuancen der Webanwendungsentwicklung schenken die meisten der zugrunde liegenden Betriebssystemumgebung, in der diese Anwendungen tats\u00e4chlich betrieben werden, nur wenig Aufmerksamkeit. Die Trennung zwischen Entwicklung (Dev) und Betrieb (Ops) hat die Situation nur versch\u00e4rft. Mit dem Aufstieg der DevOps-Kultur beginnen Entwickler jedoch, die Verantwortung f\u00fcr den Betrieb ihrer Anwendungen in der Cloud zu \u00fcbernehmen, weshalb es f\u00fcr sie sehr hilfreich ist, das Backend des Betriebssystems gr\u00fcndlich zu verstehen. Dies ist besonders vorteilhaft, wenn Sie versuchen, ein System f\u00fcr Tausende oder Zehntausende gleichzeitiger Verbindungen bereitzustellen.<\/p>\n

Einschr\u00e4nkungen in Webdiensten \u00e4hneln stark den Einschr\u00e4nkungen in anderen Anwendungen. Egal, ob es sich um Lastenausgleichsmechanismen oder Datenbankserver handelt, all diese Anwendungen haben \u00e4hnliche Probleme in einer leistungsstarken Umgebung. Das Verst\u00e4ndnis dieser grundlegenden Einschr\u00e4nkungen und Strategien zu deren \u00dcberwindung erm\u00f6glicht eine bessere Einsch\u00e4tzung der Leistung und Skalierbarkeit Ihrer Webanwendungen.<\/p>\n

Ich schreibe diese Artikelreihe als Antwort auf die Fragen junger Entwickler, die gut informierte Systemarchitekten werden m\u00f6chten. Es ist unm\u00f6glich, die Methoden zur Optimierung von Linux-Anwendungen klar zu verstehen, ohne sich mit den Grundlagen auseinander zu setzen, wie sie auf Betriebssystemebene funktionieren. Obwohl es viele Arten von Anwendungen gibt, m\u00f6chte ich in diesem Zyklus Netzwerkanwendungen und nicht Desktop-Anwendungen wie Browser oder Texteditoren untersuchen. Dieses Material richtet sich an Entwickler und Architekten, die verstehen m\u00f6chten, wie Programme unter Linux oder Unix funktionieren und wie man sie f\u00fcr hohe Leistung strukturiert.
\n<\/a><\/noindex>
\nLinux ist ein serverbetriebssystem<\/i> , und Ihre Anwendungen laufen h\u00e4ufig genau auf diesem Betriebssystem. Obwohl ich \"Linux\" sage, k\u00f6nnen Sie die meiste Zeit mit Sicherheit annehmen, dass alle Unix-\u00e4hnlichen Betriebssysteme im Allgemeinen gemeint sind. Dennoch habe ich den begleitenden Code nicht auf anderen Systemen getestet. Wenn ich also etwas Linux-spezifisches ausprobiere, weise ich darauf hin.<\/p>\n

Obwohl Sie das erworbene Wissen nutzen k\u00f6nnen, um eine Anwendung von Grund auf neu zu erstellen, die hervorragend optimiert ist, ist es besser, dies zu vermeiden. Wenn Sie einen neuen Webserver in C oder C++ f\u00fcr die Gesch\u00e4ftsanwendung Ihrer Organisation schreiben, k\u00f6nnte dies Ihr letzter Arbeitstag sein. Das Wissen \u00fcber die Struktur dieser Anwendungen hilft jedoch bei der Auswahl bereits existierender Programme. Sie k\u00f6nnen Systeme auf Basis von Prozessen mit Systemen auf Basis von Threads sowie auf Basis von Ereignissen vergleichen. Sie werden verstehen und sch\u00e4tzen, warum Nginx besser funktioniert als Apache httpd und warum eine Python-Anwendung auf Basis von Tornado mehr Benutzer bedienen kann als eine Python-Anwendung auf Basis von Django.<\/p>\n

ZeroHTTPd: Lernwerkzeug<\/h1>\n

\nZeroHTTPd<\/a><\/noindex>\u00a0\u2014 ein Webserver, den ich von Grund auf in C als Lernwerkzeug geschrieben habe. Er hat keine externen Abh\u00e4ngigkeiten, einschlie\u00dflich des Zugriffs auf Redis. Wir f\u00fchren unsere eigenen Redis-Prozeduren aus. Weitere Informationen finden Sie weiter unten.<\/p>\n

Obwohl wir die Theorie lange diskutieren k\u00f6nnten, gibt es nichts Besseres, als Code zu schreiben, ihn auszuf\u00fchren und alle Serverarchitekturen miteinander zu vergleichen. Dies ist die anschaulichste Methode. Deshalb werden wir einen einfachen Webserver ZeroHTTPd schreiben und jedes Modell anwenden: auf Basis von Prozessen, Threads und Ereignissen. Wir werden jeden dieser Server testen und sehen, wie sie im Vergleich zueinander funktionieren. ZeroHTTPd wird in einer einzigen C-Datei implementiert. Der Ereignis-basierte Server enth\u00e4lt uthash<\/a><\/noindex>, eine hervorragende Implementierung einer Hash-Tabelle, die in einer einzigen Header-Datei geliefert wird. In den anderen F\u00e4llen gibt es keine Abh\u00e4ngigkeiten, um das Projekt nicht zu komplizieren.<\/p>\n

Der Code enth\u00e4lt viele Kommentare, um beim Verst\u00e4ndnis zu helfen. Als einfacher Webserver in wenigen Codezeilen stellt ZeroHTTPd auch ein minimales Framework f\u00fcr die Webentwicklung dar. Es hat eine begrenzte Funktionalit\u00e4t, kann jedoch statische Dateien ausliefern und sehr einfache \u201edynamische\u201c Seiten erstellen. Ich muss sagen, dass ZeroHTTPd gut geeignet ist, um zu lernen, wie man leistungsstarke Linux-Anwendungen erstellt. Im Grunde genommen warten die meisten Webdienste auf Anfragen, \u00fcberpr\u00fcfen sie und verarbeiten sie. Genau das wird ZeroHTTPd tun. Es ist ein Lernwerkzeug und nicht f\u00fcr den produktiven Einsatz gedacht. Es hat keine starken F\u00e4higkeiten zur Fehlerbehandlung und wird wahrscheinlich nicht mit den besten Sicherheitspraktiken prahlen (oh ja, ich habe verwendet strcpy<\/code>) oder mit abstrusen Tricks der Sprache C. Aber ich hoffe, dass er seine Aufgabe gut meistern wird.<\/p>\n

\"Die
\nStartseite von ZeroHTTPd. Er kann verschiedene Dateitypen ausgeben, einschlie\u00dflich Bilder<\/i><\/p>\n

Anwendung f\u00fcr ein G\u00e4stebuch<\/h1>\n

\nModerne Webanwendungen sind in der Regel nicht auf statische Dateien beschr\u00e4nkt. Sie haben komplexe Interaktionen mit verschiedenen Datenbanken, Caches usw. Daher werden wir eine einfache Webanwendung namens \u201eG\u00e4stebuch\u201c erstellen, in der Besucher Eintr\u00e4ge unter ihren Namen hinterlassen. Das G\u00e4stebuch speichert zuvor hinterlassene Eintr\u00e4ge. Au\u00dferdem gibt es einen Z\u00e4hler f\u00fcr die Besucher am unteren Rand der Seite.<\/p>\n

\"Die
\nWebanwendung \u201eG\u00e4stebuch\u201c ZeroHTTPd<\/i><\/p>\n

Der Besucherz\u00e4hler und die Eintr\u00e4ge des G\u00e4stebuchs werden in Redis gespeichert. F\u00fcr die Kommunikation mit Redis wurden eigene Prozeduren implementiert, die nicht von externen Bibliotheken abh\u00e4ngen. Ich bin kein gro\u00dfer Fan davon, eigenen Code zu entwickeln, wenn es \u00f6ffentliche und gut getestete L\u00f6sungen gibt. Aber das Ziel von ZeroHTTPd ist es, die Leistung von Linux und den Zugriff auf externe Dienste zu studieren, w\u00e4hrend die Bearbeitung von HTTP-Anfragen die Leistung erheblich beeinflusst. Wir m\u00fcssen die Kommunikation mit Redis in jeder unserer Serverarchitekturen vollst\u00e4ndig kontrollieren. In einer Architektur verwenden wir blockierende Aufrufe, in anderen prozedurbasierte Ereignisse. Die Verwendung einer externen Client-Bibliothek f\u00fcr Redis w\u00fcrde diese Kontrolle nicht erm\u00f6glichen. Zudem f\u00fchrt unser kleiner Redis-Client nur einige Funktionen aus (Abruf, Einstellung und Erh\u00f6hung eines Schl\u00fcssels; Abruf und Hinzuf\u00fcgen zu einem Array). Dar\u00fcber hinaus ist das Redis-Protokoll \u00e4u\u00dferst elegant und einfach. Man muss es nicht einmal speziell lernen. Die Tatsache, dass die gesamte Arbeit des Protokolls in etwa einhundert Zeilen Code erledigt wird, zeigt, wie gut es durchdacht ist.<\/p>\n

Im folgenden Bild sind die Vorg\u00e4nge der Anwendung dargestellt, wenn der Client (Browser) anfragt \/guestbookURL<\/code>.<\/p>\n

\"Die
\nFunktionsweise der G\u00e4stebuchanwendung<\/i><\/p>\n

Wenn eine Seite des G\u00e4stebuchs ausgegeben werden soll, erfolgt ein Aufruf des Dateisystems zum Lesen der Vorlage in den Speicher und drei Netzwerkaufrufe an Redis. Die Vorlagendatei enth\u00e4lt den Gro\u00dfteil des HTML-Inhalts f\u00fcr die Seite auf dem obigen Screenshot. Dort gibt es auch spezielle Platzhalter f\u00fcr die dynamischen Inhalte: die Eintr\u00e4ge und den Besucherz\u00e4hler. Wir erhalten diese aus Redis, f\u00fcgen sie in die Seite ein und liefern den vollst\u00e4ndig formatierten Inhalt an den Client aus. Den dritten Redis-Abruf kann man vermeiden, da Redis den neuen Wert des Schl\u00fcssels beim Erh\u00f6hen zur\u00fcckgibt. F\u00fcr unseren Server mit einer ereignisgesteuerten asynchronen Architektur ist jedoch eine Vielzahl von Netzwerkaufrufen eine gute \u00dcbung zu Lernzwecken. Daher ignorieren wir den von Redis zur\u00fcckgegebenen Wert der Besucheranzahl und fordern ihn in einem separaten Aufruf an.<\/p>\n

Serverarchitekturen von ZeroHTTPd<\/h1>\n

\nWir erstellen sieben Versionen von ZeroHTTPd mit derselben Funktionalit\u00e4t, jedoch mit unterschiedlichen Architekturen:<\/p>\n