Das deutsche Python-Forum

Moin zusammen,

Ich habe festgestellt, dass meine Website nicht mehr reaktionsfähig ist, während auf demselben Webserver ein Python-Skript ausgeführt wird. Weitere Clients, die auf die Website zugreifen möchten, werden nicht bedient, was bis hin zu einem internen Serverfehler führt mit entsprechender Fehlerseite. Mein Script erstellt eine Powerpoint Präsentation und stellt auch eine Anfrage an OpenAI – es funktioniert reibungslos, nur eben lähmt es während den 10-20 Sekunden Bearbeitungszeit die gesamte Seite. Ich habe verschiedene Ansätze aus meiner Recherche heraus ausprobiert, darunter die Verwendung von Sockets in nicht-blockierender Form, sowie das Starten eines Subprocess, das war aber alles nichts. Ich suche eigentlich eine ganz einfache Lösung, um das Python-Skript einfach im Hintergrund auszuführen, ohne dass es den Zugriff auf die Website für andere Benutzer blockiert. Kenne mich aber zu wenig aus mit dem Setup von Webservern.

Auf dem Server liegt das Script in einer Environment, die ich jedes mal öffne wenn ich es aufrufe. Konkret rufe ich es so aus einer PHP Datei heraus auf:
Ist dieser Weg suboptimal In meinem Kopf schwirren verschiedene Möglichkeiten rum wie Threads, Multiprocessing und asynchrone Programmierung (z.B. asyncio?), aber ich bin mir unsicher, welcher Ansatz der einfachste und effektivste ist für mein Anliegen..

Ich verfüge über ein gutes Performance-Paket bei meinem Webhosting-Anbieter, sodass dies nicht der Grund für die Probleme sein sollte. Der Server läuft unter Linux mit Apache.

Wie bleibt die Website ansteuerbar, auch wenn das Script ausgeführt wird? Danke euch für euer Interesse, bin für jede Anregung dankbar.
LG
Marvin

Das klingt doch eher wie ein vorgelagertes Problem.
Wenn dein Benutzer auf das Resultat der Abarbeitung wartet, nützt es ja nichts, wenn da etwas "im Hintergrund" abgearbeitet wird.
Wenn deine Webserver- oder PHP-Konfiguration nur eine einzige Anfrage zur selben Zeit ausführen kann, liegt da das Problem. Nicht in Python.

Hallo,

Auf dem Server liegt das Script in einer Environment, die ich jedes mal öffne wenn ich es aufrufe.

Das brauchst du nicht. Du musst nur den Pfad zum Python-Interpreter im venv angegeben und das Skript damit aufrufen. Beispiel:
Gruß,

@gonGel954: Was denn für interne Serverfehler? Der Webserver schreibt da ja normalerweise in seine Fehlerprotokolldatei *was* da passiert ist.

Wo kommt ``$arg1`` her? Ich hoffe mal, dass da am Ende nicht irgendwelche Benutzereingaben von der Webseite in etwas eingesetzt werden was von einer Shell auf dem Server ausgeführt wird‽

Das mit der Shell sollte man sowieso nicht machen. Umgebungsvariablen kann man auch bei `proc_open()` angeben, da braucht man keine Shell für.

Führt das `chdir()` zu einem *Abbruch* falls es nicht klappt? Falls nicht, ist das etwas das man *sichertstellen* sollte, damit nicht auf einem aktuellen Arbeitsverzeichnis operiert wird, das gar nicht das ist, welches man erwartet. Und falls das sowieso nur für den externen Prozess gelten soll: auch *das* kann man bei `proc_open()` angeben.

Der Aufruf in PHP würde dann so aussehen, ohne `chdir()` vorher und ohne unnötige Shell zwischen PHP und Python (ungetestet):

Vielen Dank für den Input @sparrow, @noisefloor, @__blackjack__

Auch ohne Shell im Aufruf kommt es leider zum selben Phänomen. Die Website blockiert solange Script läuft. Btw. Arg1 beinhaltet das Template für die Präsi, die im Frontend per Dropdown ausgewählt wird. Bei einigen Zugriffen kommt es zum 500 Internal Server Error

Habe nun weitergesucht und den Übeltäter im PHP Code identifiziert. Später im Code will ich den Download Button einblenden, sobald das Python Script durch ist. Siehe Code. Sobald ich proc_close rausnehme, habe ich keine Probleme mehr. Ich kann so zumindest diese Blockade lösen. Allerdings kann ich dann nicht mehr feststellen, ob das Script fertig ist, um den Download Button oder einen Fehlercode anzuzeigen. Hier der Code:
Alternativ schaue ich gerade nach Lösungen, mit denen ich irgendwie tracken kann, ob das Python Script beendet wurde, ohne dass ich proc_close nutzen muss. Es gibt scheinbar noch $status = proc_get_status($process); aber wenn ich es in einer While Schleife einbinde, kommt es wieder zu einer Blockade.

Marvin

@gonGel954: Natürlich blockiert alles blockierende. Das HTML wird im Grunde erst ausgeliefert wenn das PHP-Skript komplett durchgelaufen ist. So etwas wie Webseite senden und danach dann noch einen Button senden geht so nicht.

Und Du hast jetzt immer noch nicht die Ursache des 500er genannt. Der Webserver schreibt da ja was in sein Fehlerprotokoll.

Wie sehe ich das Fehlerprotokoll ein?

Indem du hin navigierst und die Datei mit einem Texteditor oder less öffnest.

Wo das Protokoll liegt hängt von der Konfig des Servers bzw deines Providers ab. Standard wäre das Verzeichnis /var/log.

Und "später einen Button einblenden" geht, aber nicht so, wie du es programmiert hast, also sequentiell. Wenn du sowas willst, dann müsstest du den Bau der PP Präsentation in den Hintergrund schicken und die Webseite benachrichtigen, wenn die PPP fertig ist.Geht alles, ist aber deutlich komplexer.

Gruß, noisefloor

gonGel954 hat geschrieben: ↑Freitag 15. November 2024, 14:38 Moin zusammen,
Weitere Clients, die auf die Website zugreifen möchten, werden nicht bedient, was bis hin zu einem internen Serverfehler führt mit entsprechender Fehlerseite.

Mal so ein Schuss ins Blaue, kann es sein das du kein Web Server Gateway Interface (WSGI) zwischen deiner App und den Server hast?
Zumindest bei Flask ist der Development Server auf einen Worker beschränkt und wenn der gerade ein Request bearbeitet, laufen die anderen ins Timeout.
Mit einem WSGI Server wie gnuicorn zwischen den Webserver und der App, kannst du eine Anzahl an Workern angeben und das Problem hat sich vielleicht erledigt.

Andere Mögliche Quelle dieses Verhaltens wäre ein Webserverbetreiber der jedem Kunden nur eine gewisse Anzahl langlaufender Prozesse erlaubt.

Ich denke, WSGI können wir ausschließen. Python wird ja nur durch PHP getriggert.

sparrow hat geschrieben: ↑Montag 18. November 2024, 18:32 Ich denke, WSGI können wir ausschließen. Python wird ja nur durch PHP getriggert.

Valider Punkt, das habe ich in der Tat übersehen.