PHP Asyncron arbeiten (Thread, OS Aufruf...)

[gaunt]

Hi
wieder mal ein Problem;-)

Ich habe eine performancekritische Schnittstelle geschrieben. Beim ersten Aufruf mit neuen Parametern müssten Daten generiert werden, die dann ab dem zweiten identischen Aufruf aus einem File ausgeliefert werden.

Beim ersten Aufruf wird eine Fehlermeldung zurück gegeben und das Script muss sich beenden. Im Hintergrund muss aber völlig unabhängig das "generieren" Script laufen.

Hab mal ein bisschen im Netz geschaut.
PThread läuft auf den Servern nicht und bekomme ich auch nicht installiert. Gleiches gillt für Gearman.
Job in ein File oder DB schreiben und nen Cron jede Sekunde checken lassen? Weiß nicht...
Systemaufruf unterscheidet sich zwischen Linux (wirk) und Windows (entwicklung). Also auch nicht toll, da ich ein nicht getestetes Script auf einen Wirkserver deployen müsste. Außerdem ist sowas nicht gerne gesehen.
Socket Verbindung zu meinem Script aufbauen ist auch irgendwie schräg.

Hätte da noch jemand eine Idee?
Verstanden? Ein Script wird über den Webserver aufgerufen und muss sich sehr schnell beenden. Im Hintergrund muss ein lang laufendes Script gestartet werden.

 

[mercsen]

Wenn es zeitkritisch sein soll ist PHP ohnehin eine schlechte wahl, darf selber gerade eine PHP API umschreiben, aber egal.

Den Systemaufruf kann man dich in einer einfachen verzweigung / Klasse unterbringen? Wenn Linux mach dies, wenn Windows mach jenes.

Mir schwebt da etwas vor wie ein Objekt (nennen wir es mal Tools) das eine methode und eigenschaft hat hat wie

public static int _OS = 0; // eine zahl für win / linux / etc. oder string, array ....

public static Object exec(String param) {
     if(Tools::_OS == 1) {
          // do windows stuff
     } else {
         // do linux stuff
      }
}

das ganze schöner im switch aber soll ja nur veranschaulichen.

Quasi für alle Operatioen die anders laufen schreibst dir eine Wrapper Klasse. so musst du nur diese pflegen und kannst die überall mit ausliefern, aber bei PHP sollte das nicht alzu viel sein.

Evtl. kann dir ein NodeJS Server helfen. Minimalistischer webserver der mit JS programmiert wird. Super stabil, super schnell, super resourcenschonend.
Da könnten deine clienten zu connecten und der übernimmt dann den rest. Kannst da auch über WebSockets o.ä. eine dauerhate Verbindung zu aufbauen.

Kannst du evtl. mal beschreiben wieso dieser Vorgang so kompliziert sein muss? Mir schwebt da eine bessere Lösung vor, aber ohne genaue Kenntnise was gemacht werden soll ist das nicht sinnvoll

Wie bekommt der Client z.b. mit das die Generieriung beendet ist und was passiert wenn er währendessen nochmal verbindet? 2. anlauf der generierung? PHP muss ja auch mitbekommen das nun alles fertig ist, also müsste da auch der weg über eine DB gegangen werden. Mit Datein und zeitkritischen Operationen von mehreren Clienten wird schnell Fehleranfällig.

edit
Was mir zum Thema Threads noch einfällt. Glaube PHP ist da auch mit erweiterungen nicht wirklich für geeignet, dafür ist es einfach zu sehr dazu ausgelgt einmal zu laufen und den User erstmal zu frieden zu stellen.
Da kann dir aber auch NodeJS helfen, ist es nicht wirklich Thread Fähig so beherscht es aber die Technik von Asynchronen Funktionsaufrufen mit Callbacks. Anfangs ungewohntes aber mächtiges Werkzeug, macht das Thread Handling nicht überflüssig aber leichter.
Das einarbeiten dauert auch nicht lange da er wirklich simple gehalten wurde. Ein Einfacher Server der Verbindungen entgegen nimmt und einfach das empfangen Zurücksendet lässt sich in 10 Zeilen schreiben. Für beliebig (theoretisch) viele Verbindungen. Wenn man schon mit Java und Sockets Kontakt hatte kennt man das Prinzip.

 

[Mojo1987]

Tut mir leid aber das klingt nach klassischem "für falsche Sprache/Plattform entschieden". Mit Windows entwickeln ohne die Sache auf einem "Testsystem" das der Produktivumgebung entspricht testen zu können, macht das ganze noch schlimmer.

Auf Linux kannst du das eigentlich dennoch recht einfach machen. Ein simples exec() das eben ein anderes Script aufruft sollte doch reichen. Normalerweise kannst du das auch so aufrufen, das es einfach losrennt und dein normales Webscript trotzdem zuende läuft und was auch immer an Meldungen anzeigt. Wie du das dann getestet kriegst ist eigentlich dein Bier.

 

[Daaron]

Denk auch, hier solltest du MINDESTENS deine Entwicklungsplattform wechseln. Wenn du für Linux-Maschinen entwickelst, dann arbeite auch unter Windows. Es gibt da einige kleine "Ups, das ist ja hier doch anders" - Sachen...

Insgesamt wäre ein Wechsel auf eine andere Sprache aber definitiv angesagt. Threaded PHP ist ein ziemlicher Fall für sich. Da gibt es bessere Lösungen, bessere Sprachen. Threading ist nix für PHP. Du weißt nie, ob deine Funktionen am Ende wirklich threadsafe sind.

 

[Yuuri]

Quasi für alle Operatioen die anders laufen schreibst dir eine Wrapper Klasse. so musst du nur diese pflegen und kannst die überall mit ausliefern, aber bei PHP sollte das nicht alzu viel sein.

Und das bringt ihm was bei der Asynchronität? Das Script beendet wegen einem Timeout, da das Erstellen der Daten anscheinend länger läuft.

Node.JS bringt ihm hier auch nichts, das kann er genauso mit PHP und AJAX (mittels Polling oder einem offenen Ajax Request) oder Web Sockets lösen. Ist halt lediglich ein anderer Ansatz, der Endeffekt ist der Gleiche.

Tut mir leid aber das klingt nach klassischem "für falsche Sprache/Plattform entschieden". Mit Windows entwickeln ohne die Sache auf einem "Testsystem" das der Produktivumgebung entspricht testen zu können, macht das ganze noch schlimmer.

Das Entwicklungssystem ist vollkommen Hupe, gerade wenn es um Scriptsprachen geht. Da muss nur die Runtime/VM stimmen.

Auf Linux kannst du das eigentlich dennoch recht einfach machen. Ein simples exec() das eben ein anderes Script aufruft sollte doch reichen.

Das bringt ihm ebenso wenig, da exec schön synchron agiert und blockiert. exec kann man auch schön unter Windows nutzen (übrigens sind Backticks hier wohl besser, als jegliches exec, shell_exec, passthru o.ä.).

@ TE: Bastel dir einen Cron, der einfach eine Queue abarbeitet. Dann gibts die Daten halt erst, wenn der Prozess vollendet ist und die Output-Datei angelegt ist.

 

[Mojo1987]

Das bringt ihm ebenso wenig, da exec schön synchron agiert und blockiert. exec kann man auch schön unter Windows nutzen (übrigens sind Backticks hier wohl besser, als jegliches exec, shell_exec, passthru o.ä.).

Stimmt so nicht, du kannst exec sehr wohl so verwenden, das er eben NICHT blockiert. Schau dir einfach mal die Docu dazu an...

 

[Daaron]

Das Entwicklungssystem ist vollkommen Hupe, gerade wenn es um Scriptsprachen geht. Da muss nur die Runtime/VM stimmen.

...

@ TE: Bastel dir einen Cron, der einfach eine Queue abarbeitet. Dann gibts die Daten halt erst, wenn der Prozess vollendet ist und die Output-Datei angelegt ist.

So. Hast du schon einmal unter WINDOWS einen Cron für LINUX geschrieben, der dann ungetestet auf ein Produktivsystem kam?

Es ist eben NICHT Hupe, welches OS man zum Entwickeln verwendet. Das fängt ja schon mit den unterschiedlichen Rechte-Strukturen an. Unter Linux kann manches include() versacken, das unter Windows noch durch geht. Und auch das Basis-Verzeichnis unterscheidet sich bei PHP hinsichtlich Win und Linux.
Außerdem stehen dir auf dem Produktivserver oftmals ganz andere Bibliotheken & Versionen zur Verfügung als unter Windows. Was bringt es dir, wenn du im Windows mit PHP 5.5 entwickelst, das Zeug dann aber auf einem PHP 5.3-Server unter Ubuntu 12.04 laufen soll? Da gibt es einige Fallstricke, so hat z.B. die PHP 5.3 - Implementierung von imagick in Ubuntu einen Bug beim Erzeugen von GIFs. Da kannst du unter Windows oder einer anderen Distribution 100x lokal testen, es wird auf dem Ubuntu-Server nicht laufen.

 

[mercsen]

Und das bringt ihm was bei der Asynchronität? Das Script beendet wegen einem Timeout, da das Erstellen der Daten anscheinend länger läuft.

Node.JS bringt ihm hier auch nichts, das kann er genauso mit PHP und AJAX (mittels Polling oder einem offenen Ajax Request) oder Web Sockets lösen. Ist halt lediglich ein anderer Ansatz, der Endeffekt ist der Gleiche.

Meine Aussage bezog sich dabei auf diese Stelle im Start Post

Weiß nicht...
Systemaufruf unterscheidet sich zwischen Linux (wirk) und Windows (entwicklung). Also auch nicht toll, da ich ein nicht getestetes Script auf einen Wirkserver deployen müsste. Außerdem ist sowas nicht gerne gesehen.

Sollte also lediglich ein Tipp sein mehere Versionen umgehen zu können.

Mit dem NodeJS Server sehe ich einige Vorteile.

Wie soll man denn mit WebSockets eine Verbindung zu PHP aufbauen? Also eine dauerhafte? Wenn es geht entschuldige ich mich, dann ziehe ich diesen zweifel zurück.
Mein Gedanke dabei ist der folgende: Jeder Client connected genau 1 Mal mit dem Server. Dabei bekommt er dann die "Fehlermeldung" - besser wäre eine willkommen oder warte meldung - und tut nichts als zu warten bis der Server sagt er sei mit dem Generieren der Datein fertig. Nun sind beide im Standby Modus und sobald der Client dann wieder auf den Server zugreifen würde nutzt er stattdessen die vorhandene Verbindung und wartet auf jedenfall so lange bis der Server sagt er hat die Datein generiert. (Stichwort Semaphor).
Der Server hat somit die möglichkeit sich abzuschotten wenn zu viel los ist, bzw. die Clienten hinzuhalten, sorgt dafür das keine Timeouts entstehen und kann zudem die Datein von selber im Speicher halten, bzw. deren wichtigen Daten.

Das kann man mit PHP und AJAX in der Form nicht lösen.

PHP müsste ja zumindest bei jedem Aufruf prüfen ob entweder die Datei da / beschrieben ist oder in der DB steht das die Datein generiert wurde. Das kostet jedesmal Zeit. Wenn man mehrere Libs verwendet werden sie JEDESMAL neu geladen, wie erwähnt gibt es dafür Optimierungen aber die kommen nicht an eine richtige Client-Server Architektur heran.

Wenn es unbedingt sein muss kann NodeJS (und das kann eigentlich ein beliebiger Server sein) ja die PHP Skripte aufrufen

Man könnte das ganze ja noch weiter Spinnen und mit einem globalen Stack Arbeiten der vom Worker überwacht wird, das könnte PHP dann sogar machen, aber der Vorteil einer beidseitigen kommunikation ist dahin.

Zur Entwicklungsumgung....
WO man entwickelt ist doch egal, solange man dort TESTET wo es gebraucht wird.
Was spricht dagegen PHP auf Windows zu entwickeln wenn die IDE die Datein sofort auf den Server lädt und sich das ganze dann auch Remote Debuggen lässt?
Alternativ gibt es ja auch nicht wenige Tools, welche die Datein die man gerade bearbeitet mit denen auf dem Server Synchron hält, also nebenbei einfach ne Terminal Session gestartet und los getestet.
[Ausnahme ist natürlich Desktop Entwicklung]

P.S.

wenn das nun langsam zuweit vom eigentlichen Thema abschweift bitte ich um einen kurzen Hinweis, finde die Diskussion aber sehr spannend

P.P.S.
geht mir sehr nahe das Thema da ich exakt den Fehler gemacht habe und dachte man könnte schon irgendwie eine zeitkritische API in PHP entwickeln. Irgendwann ist ein Skript von PHP selber limitiert und kann nicht unter einen bestimmten Wert gedrückt werden. NodeJS war nur als Beispiel gedacht weil wirklich schnell erlernt, sicher und nicht hungrig ist. Man muss (aber kann / sollte) sich nicht um Threads kümmern und kann Aufgaben gut verteilen.

 

[Yuuri]

Stimmt so nicht, du kannst exec sehr wohl so verwenden, das er eben NICHT blockiert. Schau dir einfach mal die Docu dazu an...

Das ist dann aber nicht exec geschuldet, sondern bedient sich dem Trick, dass das Programm in der Shell entsprechend gestartet werden würde. Standardmäßig arbeitet es blockierend, außer man leitet es eben in ein Outfile um, plus lässt es asynchron starten. Ähnlich unter Windows mit start .... Also blockiert hier exec so lange, bis der Prozess von der übergebenen Kommandozeile gespawnt wurde, mit dem Nebeneffekt, dass die Kommandozeile, das Programm eben asynchron startet.

So. Hast du schon einmal unter WINDOWS einen Cron für LINUX geschrieben, der dann ungetestet auf ein Produktivsystem kam?

Wer verwendet beim Entwickeln Crons? Das Skript wird per CLI gestartet und damit entwickelt. Da braucht es keine Crons und verwendet man gleich PHP (per CLI gibt es defacto keinen Timeout), läuft das Teil wiederum auf jedem OS, über jeglichen Zeitraum. Man brauch keine großen Anpassungen für PHP oder Windows, insofern die Umgebung gleich ist (externe Tools bspw. in $PATH bzw. %PATH%).

Man kann doch auch wunderbar einen Daemon damit basteln, insofern die Mitteln in PHP selbst ausreichend sind. Nix anderes als mit Python/Perl, mit entsprechenden Einschränkungen.

Es ist eben NICHT Hupe, welches OS man zum Entwickeln verwendet. Das fängt ja schon mit den unterschiedlichen Rechte-Strukturen an. Unter Linux kann manches include() versacken, das unter Windows noch durch geht. Und auch das Basis-Verzeichnis unterscheidet sich bei PHP hinsichtlich Win und Linux.

Das hat aber jetzt was mit PHP oder einer Programmiersprache/VM zu tun? Das ist alles eine Konfiguration des Webservers bzw. des CLI/CGI/FPM. PHP wird hierbei nur ausgeführt und dem ist es lasch gesagt Schnurz egal, was da läuft. Wenn die Rechte hierbei nicht stimmen, kann PHP nichts dafür. Da liegt eben eine Fehlkonfiguration im Werbserver/FTP/... vor und das Teil muss unter dem richtigen User gestartet werden bzw. die Rechte entsprechend verändert werden.

Außerdem stehen dir auf dem Produktivserver oftmals ganz andere Bibliotheken & Versionen zur Verfügung als unter Windows. Was bringt es dir, wenn du im Windows mit PHP 5.5 entwickelst, das Zeug dann aber auf einem PHP 5.3-Server unter Ubuntu 12.04 laufen soll?

Da kann auch wieder was das System für? Du willst mir doch hier nicht erzählen, dass du auf deinem Entwicklungssystem die selbe Konfiguration hast oder mehrere Systeme entsprechend der Serverumgebung bootest?! Nein, da werden einfach mehrere PHP-Versionen installiert mit unterschiedlichen (optimalerweise identischen) Konfigurationen und dann ist gut. Ggf. macht man bei Versionskonflikten vorher eine Prüfung und stellt ggf. spezielle Switches an externe Programme/Bibliotheken an/aus. Zur letzten Rettung kompiliert man sich die entsprechende Version und legt sie in einem Verzeichnis ab oder aber man nutzt vorgefertigte Binaries, damit die Umgebung stimmt. Das hat aber alles nichts mit PHP selbst zu tun, sondern man fixt hier ja nur die Umgebung.

Da gibt es einige Fallstricke, so hat z.B. die PHP 5.3 - Implementierung von imagick in Ubuntu einen Bug beim Erzeugen von GIFs. Da kannst du unter Windows oder einer anderen Distribution 100x lokal testen, es wird auf dem Ubuntu-Server nicht laufen.

Und auch hier: Was kann das System dafür? Dann muss man sich an der Stelle eben eine weitgehend identische, aber bugfreie Version heraussuchen und diese nutzen. Zur Not selbst kompilieren. Ich richtige mir doch hier aber wiederum nicht die identische Konfiguration auf meinem Entwicklungssystem ein. Dafür ist dann der Testserver da, damit man die Lauffähigkeit und korrekten Output überprüfen kann.

Es ist doch hier das Selbe, wie in Java. Ist die VM installiert, läuft es einfach. Die ganze Problematik ist doch bei weitem nicht so gravierend, wenn man nur entsprechende Funktionen und Klassen nutzt, die dann alles entsprechend zurechtbiegen. Was passiert, wenn man dies nicht tut, sieht man doch hervorragend an den Entwicklern, dessen Programme unter XP released wurden, aber unter späteren Versionen evtl. nicht mehr laufen. Da kommen fixe Pfade ("C:\Dokumente und Einstellungen\...", "C:\Windows\...") rein, anstatt vordefinierte Variablen, Konstanten oder Properties zu nutzen, da wird ein Pfad einfach mittels \ zusammengesetzt, anstatt z.B. System.IO.Path.Combine in C# zu nutzen etc. pp. Die Sprache/Umgebung hat hierbei wiederum aber wenig Einfluss, wenn der Entwickler einfach zu doof ist, entsprechend vorhandene Werkzeuge zu nutzen, womit man das alles portabel halten kann. Der derbste Fehler kam ja mit der Änderung bzgl. der Maus in 8.1. Auf ein Mal waren alle Programme, welche auf nicht dafür gedachte APIs zugreifen. Ein WM_MOUSEMOVE ist eben nicht mit einem WM_INPUT als Nachricht gleichzusetzen oder entsprechend gleich auf DirectInput/XInput zu setzen. Aber entsprechend viele sind dabei auf die Gusche geflogen.

Mit dem NodeJS Server sehe ich einige Vorteile.

Natürlich mag es Vor- und Nachteile haben, aber das grundsätzliche Problem wird hierbei ja nicht gelöst, sondern einfach umschifft und neue Probleme geschaffen.

1. Node.JS muss installiert werden
2. Node.JS muss konfiguriert werden
3. Node.JS muss gewartet werden
4. evtl. Skripte konvertieren (hab mit Node.JS noch nicht all zu viel gemacht)
4. einfach umschiffen, indem man die bestehenden PHP-Skripte spawnt?
5. ...?

Wie soll man denn mit WebSockets eine Verbindung zu PHP aufbauen? Also eine dauerhafte? Wenn es geht entschuldige ich mich, dann ziehe ich diesen zweifel zurück.

Bspw. ein kleiner Chat: http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket Dafür wurden Web Sockets ja geschaffen, damit Polling abgeschafft werden kann, um eine bidirektionale Verbindung zu schaffen. Falls vom Browser nicht unterstützt, kann man ja immer noch auf Polling oder Long Polling umswitchen. Ggf. sind auch Server Sent Events brauchbar. Dafür ist aber die Problembeschreibung zu wage ("rennt in ein Timeout").

Das kann man mit PHP und AJAX in der Form nicht lösen.

Doch, wunderbar sogar. Mittels Ajax verbindest du einfach auf eine URL, wo das entsprechende Skript liegt und setzt den Timeout entsprechend hoch, sodass du solange idlest, bis der Server Daten zurück sendet (nennt sich Long Polling). Öffne mal die Developer Konsole bei Facebook, da wird 1:1 das umgesetzt. Es geht ein entsprechend langer GET-Request auf /pull?... und dieser bleibt so lange erhalten, bis ein Update kommt. Und Facebook ist im Prinzip nichts anderes als PHP, außer dass hier die HHVM läuft.

Real-time messaging:

This isn't by any means a new technique: it's a variation of Comet, specifically XHR long polling, and/or BOSH.

Wer es bebildert haben will: http://stackoverflow.com/questions/...g-websockets-server-sent-events-sse-and-comet

Wenn es unbedingt sein muss kann NodeJS (und das kann eigentlich ein beliebiger Server sein) ja die PHP Skripte aufrufen

Dann kann ich aber auch einfach das Timeout für die Skripte hochsetzen. Ich glaub das ist nicht Sinn der Sache.

WO man entwickelt ist doch egal, solange man dort TESTET wo es gebraucht wird.

Eben, meine Rede. Ausführung steht oben.

Was spricht dagegen PHP auf Windows zu entwickeln wenn die IDE die Datein sofort auf den Server lädt und sich das ganze dann auch Remote Debuggen lässt?

Funktioniert bspw. wunderbar in Kombination mit xdebug. Ein Testserver ist ja eben auch dazu gemacht, damit evtl. Probleme im Live-Betrieb identifiziert und ausgemerzt werden können.

geht mir sehr nahe das Thema da ich exakt den Fehler gemacht habe und dachte man könnte schon irgendwie eine zeitkritische API in PHP entwickeln.

Die Frage ist natürlich, was der TE genau vor hat. Sind es ein paar Diagramme, die noch vor dem Timeout generiert werden sollten, dann lässt sich sowas wunderbar von PHP bewerkstelligen. Man muss halt ein wenig experimentierfreudig sein. Lösen lässt sich alles irgendwie. Wenn die Ausführung natürlich so lange dauert, dass sich die Eingabedaten einfach nur so stapeln, dann ist PHP der komplett falsche Weg oder man muss entsprechend Optimierungsarbeit leisten (ggf. mal HHVM versuchen, natürlich nur, wenn es mittels dem normalen Weg nicht anders geht). Nächste Frage wären Abhängigkeiten. Bspw. wenn imagemagick verwendet werden soll und hierbei die Erstellung des Bildes am längsten dauert, dann kann ich hierbei auch n simples Bash-/Batch-Skript verwenden. Der Performance ist es ja hierbei egal, ob nun von PHP, der Konsole oder sonstwo der Call her kommt.

NodeJS war nur als Beispiel gedacht weil wirklich schnell erlernt, sicher und nicht hungrig ist.

Ja klar, aber eine Empfehlung ohne konkrete Anforderungen oder Bedingungen zu setzen, ist einfach wie mit nem Stock in nem Tunnel zu stochern. Evtl. hat er nur einen simplen Webhoster, deswegen vielleicht auch keine Möglichkeit zur Installation von gewissen Komponenten. Da bringt ihm der Tipp mit Node.JS herzlichst wenig, denn das kann er noch weniger installieren, außer der Hoster macht für ihn eine Ausnahme (was ich stark bezweifle).

 

[mercsen]

Facebooks PHP implementierung kenne ich, konnte mich damit aber nie anfreunden, auch wenn es ohne zweifel nicht schlecht ist.

Das keine Komponenten Nachinstalliert werden können habe ich irgendwie außer acht gelassen, sorry!

Da es aber um Grundsätzliche machbarkeit geht wollte ich einfach mal meinen Senf dazu geben

so @Yuuri:
Eines vorweg: Ich beanspruche weder das recht noch die Richtigkeit für mich, aber breite hier mal meine Gedanken aus.

Danke für den vielen fundierten Input, dennoch stellen sich mir einige fragen.
Z.b. wie kann ich denn in PHP prüfen ob die Datei generiert ist außer indem ich ein Konstrukt wie

var $ready = false;

while(!$ready) {
          if(checkReport()) {
              $ready = true;
          } else {
             sleep(1);
          }
}

hab nun elendlich lange kein PHP mehr gemacht aber wäre mir neu wenn es dort methoden gibt die eine Datei überwachen können? Aber wie erwähnt lasse ich mich gerne eines besseren belehren.

So ist in meinen Augen das Problem noch immer nicht gelöst das man erst einmal und das jedesmal wenn der client connected, ob die datei vorhanden ist und zwar nicht anhand einer Variablen im Speicher sondern durch Kontakt mit einer Datenbank oder der Datei selber.
Aber ja, wie du und ich ebenfalls sagten ist es schwer ins Blaue heraus eine Spezifikation zu Optimieren wenn man den Hintergrund nicht kennt.

Je nachdem wie lange die erstellung des Berichts dauert könnte es im schlimmsten Fall sein das der Server sich rumquält mit absagen des Requests weil im Hintergrund gerade massig Berichte generiert werden.

Ein Long Poll für den ersten Request würde natürlich Sinn machen, so kann gewartet werden bis der Bericht fertig ist und der Client stellt keine unnötigen Anfragen, aber hinterher muss PHP die Datei bei jeder neuen Anfrage komplett neu einlesen und auswerten, das ist eigentlich was mir sauer dabei aufstößt. Dieses Zustandslose verhalten und die unmöglichkeit wichtige Daten als solche über die eigentliche Aufgabe zu erhalten.

Ein ganz großes Problem hast du noch wenn der Client weggeht. Im optimal fall wird beim beenden des Programms noch ein Request an den Server gesendet um das aufräumen in die Wege zu leiten, aber da fallen mir viele Fehlerquellen ein die so ein absenden schließlich verhindern würden und dann muss man mit einem Cron o.ä. regelmäßig aufräumen und weiß nicht mal sicher ob der Client noch da ist oder nur lange Pause macht. (jaja ansonsten fliegt man auch irgendwann raus und der zustand ist unklar aber ist auch nur der extrem Fall)

Ansonsten scheine ich ds grundlegene Problem nicht begriffen zu haben. Mir ging es darum dafür zu sorgen das die requests richtig bearbeitet werden, beim ersten mal bericht anzeigen etc. und ein Werkzeug an die Hand zu geben welches nur dafür geschaffen wurde begrenzte Resourcen zu verwalten. Aber ja, nach den ausführungen von Yuuri sehe ich ein das man einen weiteren webserver wohl nicht braucht, aber ich kennen mich mit Long Polling zu wenig aus.
Wie belastet das denn eine CPU wenn da z.b. 10.000 Long Poll PHP requests warten? Dürfte einiges an Spiecher wegziehen und PHP steht ja nie wirklich Still.

 

[gaunt]

Ui, hier brauch ich erstmal nen Moment zu lesen...

Was mir beim drüber fliegen auffällt:
@Plattform
Die kann ich mir leider nicht aussuchen. Ebensowenig wie die Rechner auf denen ich entwickle.
@Zusätzliche Komponenten
Ich kann fragen ob es geht. Aber im Prinzip geht erstmal nur, was in der Linux Distri enthalten ist. Unsere Server Futzies sind bemüht eine einheitliche Plattform zu betreiben (was ja auch nachvollziehbar ist!) bei der Stabilität das oberste Kriterirum ist. Da geht eben nicht jede Sonderlocke.

Was spricht dagegen PHP auf Windows zu entwickeln wenn die IDE die Datein sofort auf den Server lädt und sich das ganze dann auch Remote Debuggen lässt?

Wenn ich das mache werde ich standrechtlich erschossen, nachdem ich gevierteilt und gehäutet wurde;-) Das sind live Server. Auf denen wird nicht entwickelt und erst recht nicht debugt.
Aber das mit Exec kann ich bestimmt mal auf nem alten im Moment nicht aktiven Frontend Server testen. Dafür langt ja ein überschaubares Testscript.

Die Frage ist natürlich, was der TE genau vor hat.

Ein CMS braucht JSON Daten fürs Frontend. Diese beziehe ich aus einer SOAP Schnittstelle. Das CMS wartet höchstens eine viertel Sekunde, der SOAP Aufruf kann leicht mehrere Sekunden dauern. Leider bekomme ich vom CMS beim Publizieren keinen Push mit der Info was über SOAP abgefragt werden soll. Diese Info kommt erst beim ersten Abrufen der Daten. Und nur hier hab ich ein Problem.
Denn ich muss innerhalb der viertel Sekunde dem CMS sagen das die Daten nicht da sind und mein Script beenden. Im Hintergrund sollen dann die Daten über SOAP bezogen und in ein File vorkonfektioniert werden. Bei folgenden Aufrufen wird dann nur das File ausgespielt, was ja sehr schnell geht.


Und jetzt guck ich mal die Details an und probier das mit dem Systemaufruf mal. Und vielleicht kann ich ja auch mal einem der Server Götter ein Schokokoladenopfer darbringen um ihn milde zu stimmen;-)

 

[Kanibal]

Ich denke, Du möchtest IPC. Im Speziellen: Semaphore und MessageQueues.

Ansonsten solltest Du mMn auch über eine Staging-Linux-VM zum Testen nachdenken.

 

[rephluX]

Bin mir nicht sicher ob es damit funktioniert, aber beim Lesen des Beitrages fiel mir direkt RabbitMQ ein:

Stehen Entwickler vor Anforderungen, die zeitintensive Berechnungen oder die Verteilung von nachgelagerten Prozessen auf heterogene Systemteile erfordern, bietet RabbitMQ Grundlagen für die Umsetzung von Lösungen.

Und eine lokale Linux-Entwicklungsumgebung würde ich auch befürworten

 

[ice-breaker]

Eine lokale Umgebung, die so wie der Server konfiguriert ist, sollte schon sein. Das ganze ist heute ja auch dank Vagrant auch kein Hexenwerk mehr. Und wer sich auf keinen Fall in Puppet oder Chef einarbeiten will, kann auch auf PuPHPet die Maschine mit der Software direkt online konfigurieren.