portunusd

Portunusd

Kiste Dokumente Roadmap -Tweets

portunusd ist ein Netzwerkanwendungsserver, der von OpenBSD's relayd und Erbstück Unix inetd inspiriert ist. Es hört auf eine eingehende Netzwerkverbindung, wobei die eingehenden Daten über eine Illumos -Tür an die beabsichtigte Anwendung weitergeleitet und die Antwort auf ähnliche Weise zurückgegeben werden. portunusd ordnet jeweils verbundene Port an eine Tür auf dem von der Zielanwendung bereitgestellten Dateisystem ab.

 sequenzieren
    Teilnehmerkunde
    Teilnehmer Portunusd
    Teilnehmertür
    Teilnehmeranwendung
    Anwendung->> Tür: create /var/run/app.door
    Portunusd->> Tür: Öffnen
    Portunusd->> Portunusd: Hören Sie Port 80 an
    Schleifengriffe Anfragen
        Client->>+Portunusd: HTTP-Anfrage senden
        Portunusd->>+Anwendung: Anforderung über Door_call weiterleiten
        Anwendung->>-Portunusd: Antwort über Door_return senden
        Portunusd->>-Client: HTTP-Antwort senden
    Ende

Das Hauptziel von portunusd ist es, die Skalierung von Anwendungen mit einem Threaden zu erleichtern. Unter dem inetd -Modell wird ein neuer Prozess erstellt, um jede Anfrage zu bewältigen. Durch die Nutzung von Türen kann portunusd nur dann einen neuen Thread im Bewerbungsprozess erstellen, wenn ein neues Hochwassermark der Parallelität erreicht wurde. Andernfalls werden vorhandene Threads wiederverwendet, um nachfolgende Anfragen zu bearbeiten.

Problemanweisung

Wir möchten, dass unsere netzwerkgerichteten Anwendungen gemäß der Benutzerbedarf skalieren. Wir möchten die Ressourcenkosten unserer Anwendungen minimieren, wenn sie im Leerlauf sind, und wir möchten unsere Kosten in Bezug auf die Nachfrage linear halten. Wir möchten den Grad minimieren, in dem der Anwendungsentwickler für das Ressourcenmanagement verantwortlich ist, und wir möchten (so weit wie möglich) die vertraute Entwicklungsumgebung von UNIX -Befehlszeilen -Tools beibehalten.

Wenn Sie beispielsweise eine Rubin auf Rails-Anwendung mit einem Thread-Ruby auf Rails pflücken, kann dies eine Benutzeranforderung gleichzeitig verarbeiten. Mehrere gleichzeitige Anfragen können nicht ohne mehrere Kopien des in Speicher ansässigen Anwendung (auf separaten Ruby -Dolmetschern) behandelt werden. Dieses Modell verbraucht viel Speicher, auch wenn nur wenig Benutzerbedarf besteht, was es dem Host schwierig macht, andere Workloads auszuführen. Es kommt zu viel Paging und Knirschen der Festplatte.

Umgebungen wie node.js befassen sich mit diesem Problem, indem sie Asynchronizität für den Programmierer transparenter machen. Es kann zwar nützlich sein, die asynchrone Natur von Computern zu nutzen, aber es hat auch Änderungen in Sprachen eingeführt, die sie unterstützen. Dies ist keine bloße Veränderung der Syntax, sondern auch eine nicht triviale Änderung des mentalen Modells, mit dem man Programme lesen, schreiben und verstehen.

Am anderen Ende des Spektrums erfordern CGI -Anwendungen für jede Anfrage einen eindeutigen Prozess und Adressraum. Diese Anwendungen können linear mit der Benutzerbedarf skalieren, einschließlich execv(2) Skalierung auf Nullspeicher / CPU -Nutzung im Leerlauf.

Der postmoderne "serverlose" Ansatz erfüllt diese Kriterien, aber auf Kosten des Abgabe des Betriebssytems . Es ist ein äußerst unbekannter Ansatz für die Entwicklung von Software und wirft viele Tools weg, mit denen die Anwendung zur Laufzeit beobachtet und debuggen.

These

Türen ermöglichen ein neues (altes?) Modell der Netzwerkanwendungentwicklung, bei dem die Entwickler für die Aufrechterhaltung und Verständnis einer linearen, synchronen Aufgabe verantwortlich sind, während der Betriebssystem + Webserver zusammen mit dem Skalierungsproblem zusammenarbeitet

• Wenn eine Anwendung im Leerlauf ist, wird nur eine einzige Kopie von im Speicher benötigt.
• Wenn eine Anfrage in das System eintritt, kann sie von einem vorhandenen Thread behandelt werden.
• Es werden nur neue Themen erstellt, wenn ein neuer Peak der Parallelität erreicht wird.

Diese Eigenschaften ermöglichen es uns, unsere Problemanweisung zu beheben, indem wir Netzwerkanwendungen entwickeln, die sich wie einsthread-UNIX-Befehlszeilen-Tools anfühlen, im Leerlauf einen minimalen Aufwand darstellen und linear auf einer Erzählkörnung skalieren.

Natürlich werden Türen allein nicht über die Grenze einer einzelnen Betriebssysteminstanz übergehen, aber eine Zusammenarbeit im Relayd-Stil mit der Firewall könnte dies erleichtern, vorausgesetzt, Kopien der Anwendung sind auf mehreren Hosts verfügbar. Hier kommt portunusd ins Spiel.

Anerkennung

Das Bild soziale Medienvorschau stammt von Loudon Dodd - eigener Arbeit, CC BY -SA 3.0.

Viele obskure Illumos / Rost / Doors -Fragen wurden von @jasonbking beantwortet.