Dennis Rönnau edited this page Sep 9, 2017 · 7 revisions

Willkommen im PBExpress Dokumentations-Wiki

Was ist PBExpress?

PBExpress ist ein leichtgewichtiges serverseitiges Framework zur Entwicklung von Webanwendungen mit Hilfe der FastCGI-Schnittstelle. Die Motivation hinter diesem Projekt ist es, extrem schnelle Anwendungen zu entwickeln, ohne den Code interpretieren zu lassen, wie es z.B. bei PHP der Fall ist. Als Programmiersprache wird PureBasic verwendet. Bei PureBasic handelt es sich um einen kommerziellen Basic-Dialekt, der im Ansatz an Visual Basic bis Version 6 angelehnt ist. Der große Vorteil an PureBasic ist, das die Sprache bereits viele Bibliotheken und direkt einsetzbare Prozeduren mitbringt, um zum Beispiel mit Datenbanken, regulären Ausdrücken, Dateien und dem Dateisystem, Grafiken und vielem mehr zu arbeiten, ohne extra Bibliotheken und Header zu suchen, wie es bei C, C++ oder auch FreePascal oder FreeBasic der Fall ist. Seit relativ kurzer Zeit beherrscht PureBasic auch den Umgang mit FastCGI. Doch leider ist FastCGI vom Grundsatz her recht alt und besitzt nur eine recht einfache Funktionalität, was aber leider auch den Umgang mit der Bibliothek erschwert.

Ein Knackpunkt ist das Routing. Während man bei CGI noch für jede einzelne Anwendung eine eigene Binary kompilieren kann und das Managing dem Webserver überlässt, ist dies bei FastCGI kontraproduktiv. Den erheblichen Geschwindigkeitsvorteil erkauft man sich mit einer Binary, in der alles enthalten sein muss. Das macht es allerdings schwer, die einzelnen Seiten zu kapseln und somit den Sourcecode vernünftig zu verwalten. Der Ansatz von PBExpress besteht darin, alle Seiten in einzelne Prozeduren zu kapseln und das Routing über Callbacks zu erledigen.

Aber warum FastCGI?

  1. Laufzeit: CGI hat wie schon angesprochen den großen Nachteil, das alle einzelnen Seiten auch in einzelne Binaries verpackt werden müssen. Würde man PBExpress nun zur Verwendung mit CGI benutzen und alle Prozeduren in eine Binary packen, so muss der gesamte Code in den Arbeitsspeicher geschafft werden und kommt erst dann zur Ausführung. Dies mag bei kleineren Projekten vielleicht kein Problem darstellen. Aber bei einem vielbesuchten Projekt ist ein vServer schneller überfordert, als es einem lieb ist. FastCGI hingegen wird einmal gestartet und läuft ohne Unterbrechung durch. Alle Routinen bleiben permanent im Arbeitsspeicher und PBExpress routet die Requests nur noch auf die Prozeduren. Bei PHP und anderen Skriptsprachen gibt es ein ähnliches Problem wie bei CGI. Wird das Caching nicht richtig konfiguriert, muss bei jedem Aufruf der Skriptcode Just-in-Time interpretiert werden. Das bremst den Server erheblich aus.

  2. Skallierbarbkeit: CGI und Co skallieren selbststänig. ein Webserver nimmt eine gewisse Anzahl an Requests entgegen und wenn es sein muss, startet er die CGI Anwendung natürlich auch so oft wie nötig. Das Betriebssystem kümmert sich um die Ressourcen-Verteilung. Das klingt ja für den Anfang doch sehr gut. Das Problem ist aber, das man nur bedingt Kontrolle darüber hat. FastCGI gibt einem die Möglichkeit, mit Hilfe des LoadBalancers eines Webservers die Ressourcenverteilung ideal auf die Hardware abzustimmen und dabei immernoch Ressourcen für andere Anwendungen frei zuhalten. Wenn die Anwendung im Idle 20 MB RAM verbraucht und die Content-Length auf 10 MB begrenzt ist, so kann man theoretisch bei einem GB RAM die Anwendung ca. 34 mal auf unterschiedlichen Ports laufen lassen und den Loadbalancer auf diese Instanzen verteilen. Bei einer durschnittlichen Lastzeit von ca. 200 bis 500 ms lassen sich so theoretisch bis zu 10.500 Anfragen die Minute verarbeiten. Aber seien wir mal ehrlich. 8 Instanzen reichen auch und es bleibt noch genug für einen Teamspeak, Mumble, Mail oder VPN-Server übrig. Außerdem lässt sich jederzeit weitere Instanzen aufschalten, sollte es dennoch knapp werden.

  3. Monitoring: Wer es auf die Spitze treiben möchte, kann mit Hilfe eines zweiten Threads die Arbeit der FastCGI-Server beobachten. Die Monitore können einem Mails zusenden um zu zeigen, das sie noch laufen. CGI hat keine permanente Laufzeit, was die Überwachung des Betriebs und des Zustandes äußerst kompliziert macht. Zu welcher Tageszeit ist der Server am meisten ausgelastet? Was für Informationen versucht man, auf das System zu schieben? Während CGI für das sammeln solcher Informationen einen Request vollständig belegt und die Verbindung offen hält, kümmert sich bei FastCGI ein nebenläufiger Thread um diese Sachen und der Hauptthread kann sich um den User kümmern.

Es gibt bestimmt noch mehr Gründe für FastCGI. Aber irgendwann muss es auch hier weitergehen.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.