PHP-Script aufrufen, ohne die Antwort abwarten zu müssen

[mapcado]

Du hast Recht. Die max. Anzahl der Requests ist pro 24 Srunden auf 5000 beschränkt, und das würde auf jeden Fall eng werden. Allerdings hat man, sobald man seine Anwendung zertifizieren lässt (was angeblich nicht besonders schwer sein soll) gar keine Restriktionen mehr, außer der, dass nur 18 Requests gleichzeitig erlaubt sind.

Und zu deiner Rekursionslösung: Bei mir liegt das Problem nicht, wie in deinem Beitrag hier, darin, dass ich die max_execution_time evtl. überschreiten muss, sondern darin, dass das Script, welches makeCalls.php aufruft, die Antwort abwarten muss, die evtl. sehr lange dauern kann. Und das ist bei deiner Rekursionslösung, wenn ich das so richtig überblicke, doch auch der Fall, oder?

Um zu verdeutlichen, was eigentlich gemacht werden soll, habe ich mal den grundsätzlichen Aufbau mit Paint aufgezeichnet. Sieht hässlich aus, trifft es aber ungefähr. Der Client braucht die Request-ID von initialize.php, um den Status abfragen zu können, und auch um anschließend die Ergebnisse herunterzuladen. Wenn initialize.php erst abwarten muss, bis makeCalls.php fertig ist, gibt es keine Statusanzeige, und das vergrault die User, wenn sie evtl. über 10 Sekunden werten müssen. Noch schlimmer, evtl. führt makeCalls.php noch munter einige weitere Requests durch, und der Client muss warten, obwohl seine Ergebnisse längst da sind - weil er keine Request-ID zum Herunterladen der Ergebnisse bekommt.

Und ich habe einen Virtual VPS. Ich werd am Montag mal anfragen, aber bin nicht sehr zuversichtlich, was die Installation eines solchen Servers anbelangt. Aber fragen kost ja nix...

Vielen Dank euch beiden für die guten Tipps, aber wies aussieht, werde ich das wohl so machen müssen, dass ich makeCalls.php mit der Request-ID durch den Client aufrufe.

Obwohl mir gerade ein "genialer" Gedanke kommt ;-): Könnte man nicht zwischen makeCalls.php und initialize ein weiteres Script schalten, welches nur die Aufgabe hat, die Optionen von initialize.php entgegenzunehmen, und an makeCalls.php weiterzuleiten. Jetzt setzt man die max_execution_time für dieses Script auf 1s, und Zack - makeCalls.php läuft, aber initialize.php muss nur eine Sekunde warten, bis er dem Client die Request-ID geben kann. Das muss ich gleich heute mal ausprobieren. Ich sag dann Bescheid, obs klappt.

Viele Grüße!

 

[chmee]

Thema Vergraulen von Usern
Grundsätzlich teile ich diese Meinung, ABER wenn ein Service gut/es wert ist, ist das ein minderes Problem. Siehe bfbcs.com, die haben Wartezeiten von bis zu 10 Stunden, erfreuen sich aufgrund des Service höchster Beliebtheit (~80.000+ Requests/Stunde), obwohl sie reell nur von ~50 Spielern pro Minute Daten vom offiziellen Server saugen dürfen.. Heisst also das Verhältnis liegt bei 50:1333..

Versuch Deine Idee, sowas fällt einem oft dann ein, wenn man die "Schaltlogik" mal aufgezeichnet hat

p.s. Wie sieht es denn aus, wenn Du im Ajax-Request anstatt ReadyState 4 schon bei ReadyState 3 Daten entgegennimmst? Somit darf das Script im Hintergrund weiterarbeiten, obwohl Du gleich als Erstes die Request-ID zurückgesendet und erfolgreich verarbeitet hast.

p.p.s.: Übrigens, hast Du Dir Gedanken gemacht, ob Du nicht die Anzahl der API-Queries/Zugriff senken kannst, indem Du Anfragen kombinierst? Das halte ich für eine sinnvolle Maßnahme.

weniger Queries/User = schnellere Seitenzugriffe und mehr User/Tag realisierbar

mfg chmee

 

[mapcado]

Hallo nochmal.

Mein Versuch hat leider nicht geklappt. Ich habe einfach ein weiteres Script mit folgendem Inhalt erstellt:

$ch = curl_init("http://localhost/makeCalls.php");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// hier noch verschiedene weitere Optionen ausprobiert, siehe unten
curl_exec($ch);

Hier die Optionen, die ich versucht habe:

curl_setopt($ch, CURLOPT_TIMEOUT, 1);

Bricht die Verbindung zwar nach 1 Sekunde ab, aber auch makeCalls.php wird nur eine Sekunde lang ausgeführt.

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 1);

Gilt nur für den Verbindungsaufbau.

Außerdem habe ich noch versucht, die Ausführungszeit des Scripts einfach mit

set_time_limit(1);

zu begrenzen. Das funktioniert leider auch nicht. Die Anfrage wird komplett durchgeführt (was deutlich länger als eine Sekunde dauert), aber am Ende gibt es doch die Fehlermeldung "Maximum execution time of 1 second exceeded" Kann mir das mal einer erklären?

Trotzalledem ist, denke ich, der erste Ansatz mit

curl_setopt($ch, CURLOPT_TIMEOUT, 1);

der vielversprechendste. In diesem Fall läuft es so: Ich lege fest, dass die Ausführung des curl-Befehls (ohne HTTP-Anfrage) nur 1 Sekunde dauern darf. Wenn die vorbei ist, wird die Anfrage aufgehoben. Der Server merkt das, und bricht das Script ab. Zugegeben, diese Erklärung klingt ungefähr so, als käme sie aus der Sesamstraße, aber habe ich das jetzt halbwegs richtig wiedergegeben? Ich kenne mich mit dem Aufbau von HTTP-Anfragen leider nicht besonders aus, und auch aus dem Herrn Google konnte ich auf die Schnelle nichts rauskitzeln. Daher meine Frage: Kann man innerhalb eines PHP-Scripts irgendwie festlegen, dass es auf jeden Fall bis zum Ende ausgeführt werden soll, auch wenn die HTTP-Anfrage abgebrochen wurde, z.B. durch Änderung der php.ini, oder Manipulation irgendwelcher Server-Variablen? Oder kann man irgendwas in den HTTP-Header des Requests reinsetzen, das den Abbruch des Scripts verhindert?

@chmee: Zum Thema Vergraulen von Usern stimme ich dir durchaus zu, und ich hoffe auch, dass ich mit dem ganzen Kram hier einen Dienst bieten kann, auf den es sich 10-20 Sekunden zu warten lohnt, zumal man sich dadurch evtl. stundenlanges Suchen bei eBay ersparen kann. Aber einen Besucher so lange ohne Statusbalken im Regen stehen zu lassen, ist nicht unbedingt die feine Art
Und was das Senken der Request-Anzahl anbelangt: Ja, auch da versuche ich durch zig Fallunterscheidungen immer so wenig Anfragen wie möglich zu senden. Allerdings ist das mit den 5000 Requests nur eine Übergangslösung. Sobald die Website fertig ist, werd ich sie für die Zertifizierung anmelden, und wenn alles glatt läuft, hab ich dann ca. eine Woche später keine Restriktionen mehr (eben bis auf diese 18 Requests gleichzeitig).