FastCGI mit FreePascal, wie modular?

[Benedikt Magnus]

Hallo zusammen,

ich experimentiere derzeit mit FastCGI herum (also bisher kein Produktiveinsatz und keine Zeitnot). Ich wollte nur PHP loswerden.
Umgebung ist ein 64-Bit Debian mit Apache.

Ich habe es geschafft, eine solche Anwendung zu erstellen und zum Laufen zu bringen.
Nun wollte ich, anstatt alles zusammen zu kompilieren und immer wieder den Server neustarten zu müssen, das ganze modular aufbauen: Also Bibliotheken.
In der Aufrufroutine der FastCGI-Anwendung wird dafür, entsprechend der Anfrage, eine SO geladen und ihre Ausgabe weitergereicht.
Nun ist das ziemlich unschön, weil ich dann für Parameter, Cookies, Dateiup- und Download etc. eine eigene Schnittstelle schreiben und kompatibel halten müsste...
Also, so faul wie ich war, habe ich einfach cmem (gemeinsamer Speichermanager) sowie die FastCGI-Unit in der SO eingebunden und übergebe bei Aufruf nun die beiden Objekte für Anfragen und Ausgaben. Das klappt auch ziemlich gut!

Einziges Problem nur: Die SO ist jetzt 1,1 MB groß (vorher 200kb, die FastCGI-Anwendung hat jetzt mit den gleichen Units und noch mehr 330kb ). Etwas unschön, wenn jede Seite tausendmal größer ist als ihr PHP-Pendant...
So etwas wie BPLs scheint es mit FreePascal auch leider noch nicht zu geben...

Daher nun meine Frage:
Kennt hier jemand eine Möglichkeit, die SOs zu verkleinern oder besser einzubinden oder aber einen ganz anderen Ansatz für solch ein modulares System?
Ich bin dahingehend für alles offen!

Dankeschön!

[Lemmy]

Zitat von Benedikt Magnus:

und immer wieder den Server neustarten zu müssen, das ganze modular aufbauen

ich portiere gerade eine Delphi Windows-CGI mit FPC auf Linux, verwende aber dafür ein "einfaches" CGI, kein FastCGI. Nach dem Compilieren schiebe ich das Kompilat aber lediglich in das definierte CGI Verzeichnis - einen Server muss ich dafür nicht starten. Ist das eine Besonderheit von FastCGI?

Grüße

[Benedikt Magnus]

Ja, der Unterschied zwischen CGI und FastCGI ist der, dass bei Aufruf der Seite nicht immer wieder eine neue Instanz des Programms erzeugt wird, sondern dieses durchgehend im Hintergrund läuft und die Anfragen entgegennimmt. Das ist, aufgrund der dadurch nicht notwendigen Prozesserzeugung, schneller und ressourcenschonender möglich.

Bei Skriptsprachen wie PHP oder Python ist die FastCGI-Anwendung ein Interpreter, der die Skripte ausführt und cached (im Gegensatz dazu, dass für jeden Aufruf eine neue Interpreterinstanz erzeugt wird).

[Lemmy]

Ah Danke... wieder was gelernt...

[edit]:Warum baust Du dir dann kein Buildscript, das den Server anhält, fpc kompiliert, so kopieren und Server wieder starten... Nur dafür die Architektur zu verbiegen kommt mir "falsch" vor....

[Benedikt Magnus]

Weil es mir um die modulare Idee geht. Natürlich könnte man das alles in eine Anwendung packen und den Server kurz neustarten, aber praktischer, und interessanter, wäre es doch, wenn man einfach, wie ein PHP-Skript, eine Datei ins Verzeichnis packte und die Ausgabe einfach über den Namen performant zu erreichen wäre.

Und eigentlich müsste das ja gehen. Da alle Bibliotheken größtenteils denselben Code verwenden (dieselben Units und Packages) müsste sich das doch eigentlich auslagern lassen, bis man nur noch wenige Kilobyte pro Datei hat...
Oder träume ich da nur?

[MichaelT]

Smart linking mal probieren.

---
Die Binaries stehen im Buffer vom Filesystem
---

Kurz mein Einwand.

So wie ich das sehe.

Fast CGI Executable -> 1:n Modules -> m:1 Commando Prozessor (Interpreter) Module *), letzteres wird (im Moment noch) statisch gelinked am Ende, soferen das Framework das die Website baut nochmal in eine SO kommt.

*) Im Sinne was alle deine Webpages verbindet, deswegen bin ich mit dem Ausdruck Interpreter ein wenig vorsichtig.

DB Sessions?
Session zum Datenaustausch allgemein?
Was wäre die logische Konsequenz selbst wenn kein weiteres Sessionsmanagment notwendig wäre. Die HTML Datei bleibt extern und beinhaltet die Kommandos für den Kommandointerpreter . Das läuft auf SSI raus und Rückzug des 'Commandointerpreters' in die Fast CGI Executable.

Der Vorteil deines Vorschlags liegt in der Glättung des Speicherbedars.

Was du machst gibt es wohl. Vorgenerieren von Webpages in Caches. Dann macht das Sinn. Weiters wäre der Vorteil, dass du die Sammlung der PHP Seiten nicht musst packen. Im schlimmsten Fall komprimierst du die Exe, was in der Regel nicht notwendig wäre.

Ich habe mir FAST-CGI eher im Umfeld von 'Services' angeschaut. Dort ist die Sinnhaftigkeit unbestritten.

Sobald du bspw. in die Gegend Embedded or geringer Speicher kommst, dann kommt schnell ein Schwenk in Richtung SSI.

Zitat von Benedikt Magnus:

Weil es mir um die modulare Idee geht. Natürlich könnte man das alles in eine Anwendung packen und den Server kurz neustarten, aber praktischer, und interessanter, wäre es doch, wenn man einfach, wie ein PHP-Skript, eine Datei ins Verzeichnis packte und die Ausgabe einfach über den Namen performant zu erreichen wäre.

Und eigentlich müsste das ja gehen. Da alle Bibliotheken größtenteils denselben Code verwenden (dieselben Units und Packages) müsste sich das doch eigentlich auslagern lassen, bis man nur noch wenige Kilobyte pro Datei hat...
Oder träume ich da nur?

[MichaelT]

Nimmst du FCL Web?
Kannst ruhig mal ins Brook Framework reinschauen...

Wie oben bemerkt, das Zusammenfassen von Gemeinsamkeiten beim Generieren einer Webpage ist nicht so einfach.

Leider habe ein wenig zu wenig Information, ob es sich um Webpages handelt, ein Website Management bspw... oder ein Webapplikation die viel von OS Befehlen lebt oder viel externe Kommunikation mit bspw. Message Brokern, Datenbanken, Data Services bewerkstelligt.

Data Services lassen sich auf die von die vorgestellte Art sehr gut realisieren. Allein bei WebPages ist das verbindende Gemeinsame der Struktur entweder in eine Template ganz gut aufgehoben oder gleich die HTML Tags.

Dann musst du noch auf das Caching aufpassen usw... Wenn du die Webpages gleich in einem Cache hältst usw... dann wäre die Idee die Ressourcen in Form von SOs zu laden gar nicht so übel. Stellt sich dann die Frage, ob wir auf dem Weg nicht den Webserver und dessen Optimierungsversuche kaltstellen.

Zitat von Benedikt Magnus:

Weil es mir um die modulare Idee geht. Natürlich könnte man das alles in eine Anwendung packen und den Server kurz neustarten, aber praktischer, und interessanter, wäre es doch, wenn man einfach, wie ein PHP-Skript, eine Datei ins Verzeichnis packte und die Ausgabe einfach über den Namen performant zu erreichen wäre.

Und eigentlich müsste das ja gehen. Da alle Bibliotheken größtenteils denselben Code verwenden (dieselben Units und Packages) müsste sich das doch eigentlich auslagern lassen, bis man nur noch wenige Kilobyte pro Datei hat...
Oder träume ich da nur?

[Benedikt Magnus]

Zitat von MichaelT:

Smart linking mal probieren.

Ist aktiviert.

Zitat von MichaelT:

Fast CGI Executable -> 1:n Modules -> m:1 Commando Prozessor (Interpreter) Module *), letzteres wird (im Moment noch) statisch gelinked am Ende, soferen das Framework das die Website baut nochmal in eine SO kommt.

Wie meinst du das?

Zitat von MichaelT:

Nimmst du FCL Web?
Kannst ruhig mal ins Brook Framework reinschauen...

Ja, genau, in Lazarus das Package lz_fpweb.

In Brook habe ich auch kurz reingeschaut, fpWeb schien da aber angenehmer. Hat es irgendwelche Vorteile?


Und hast du einen Vorschlag?

[MichaelT]

Ich habe mir das Thema auch schon mal überlegt.

Soviel ich verstanden habe läuft die FAST CGI Executable und lädt Libraries und in letzteren steckt die Gernerierung der Webpage.

Die Logik des Aufbaus einer Webpage über alle Pages gesehen entspricht nicht dem Ansatz über Formulare (VCL From). Aus dieser Sicht im Vergleich zu einer Desktop Applikation lädst du kleine 'Executables' in eine DLL, wenn man so will - nämlich aus der Sicht der Wiederverwendung.

Du kannst ruhig Funktionen in Libraries auf die Art laden und dem Framework hinzufügen. Wo ich vorsichtiger wäre ist eben das generieren der Website und den OS Zugriff bspw. oder DB Zugriff in genau die Library zu packen welche im Rahmen der Generierung geladen wird. Du linkst praktisch *eine Art spezifische Runtime (Erweiterung) * statisch und selbst wenn du eine 'DLL' für das Gemeinsame bemühst, dann verlierst du schnell die Kontrolle. Man würde dann das Problem einer hängenden Ausführung im Vergleich in einer ISAPI.dll (wie früher) allein sistieren und verlagern.

Es hat sich einfach bewährt die Funktionsebene sprich eine wohldefinierte Menge die diese 'Runtime' (Erweiterungen) anbieten von der Contentgenerierung zu trennen und eine Stelle zu packen an derer Stelle wird die Webseite durchgeschleust.

Ich stelle mich eher die Frage ob man nicht in den Modulen welche die Webpage beinhalten (soferen das überhaupt so passiert) nicht einfach zur Ressoucendatei degradiert.

Zitat von Benedikt Magnus:

Zitat von MichaelT:

Fast CGI Executable -> 1:n Modules -> m:1 Commando Prozessor (Interpreter) Module *), letzteres wird (im Moment noch) statisch gelinked am Ende, soferen das Framework das die Website baut nochmal in eine SO kommt.

Wie meinst du das?

Zitat von MichaelT:

Nimmst du FCL Web?
Kannst ruhig mal ins Brook Framework reinschauen...

Ja, genau, in Lazarus das Package lz_fpweb.

In Brook habe ich auch kurz reingeschaut, fpWeb schien da aber angenehmer. Hat es irgendwelche Vorteile?


Und hast du einen Vorschlag?

[Benedikt Magnus]

Zitat von MichaelT:

Soviel ich verstanden habe läuft die FAST CGI Executable und lädt Libraries und in letzteren steckt die Gernerierung der Webpage.

Genau, so ist mein aktueller Aufbau. Ich bin aber für jeden anderen Vorschlag offen!

Zitat von MichaelT:

Die Logik des Aufbaus einer Webpage über alle Pages gesehen entspricht nicht dem Ansatz über Formulare (VCL From). Aus dieser Sicht im Vergleich zu einer Desktop Applikation lädst du kleine 'Executables' in eine DLL, wenn man so will - nämlich aus der Sicht der Wiederverwendung.

Wie meinst du das?

Zitat von MichaelT:

Du kannst ruhig Funktionen in Libraries auf die Art laden und dem Framework hinzufügen. Wo ich vorsichtiger wäre ist eben das generieren der Website und den OS Zugriff bspw. oder DB Zugriff in genau die Library zu packen welche im Rahmen der Generierung geladen wird. Du linkst praktisch *eine Art spezifische Runtime (Erweiterung) * statisch und selbst wenn du eine 'DLL' für das Gemeinsame bemühst, dann verlierst du schnell die Kontrolle. Man würde dann das Problem einer hängenden Ausführung im Vergleich in einer ISAPI.dll (wie früher) allein sistieren und verlagern.

Aber ist nicht auch genau das, was bspw. PHP macht?

Zitat von MichaelT:

Es hat sich einfach bewährt die Funktionsebene sprich eine wohldefinierte Menge die diese 'Runtime' (Erweiterungen) anbieten von der Contentgenerierung zu trennen und eine Stelle zu packen an derer Stelle wird die Webseite durchgeschleust.

Templates wären ja immer noch möglich, und mache ich nicht genau das? Oder verstehe ich dich falsch?

Zitat von MichaelT:

Ich stelle mich eher die Frage ob man nicht in den Modulen welche die Webpage beinhalten (soferen das überhaupt so passiert) nicht einfach zur Ressoucendatei degradiert.

Aber eine Ressoucendatei kann doch keine Programmlogik beinhalten?