curl_multi langsam

[AmicaNoctis]

Das Script das ich parallel 30fach aufrufen möchte, dient als Proxy Script das bestimmte APIs aufruft. Zugriff auf die API hab ich nur von meiner Server IP. Aber so kann ich die Api auch von anderen IPs nutzen.

Klingt trotzdem nicht besonders gut. Gibt es zu dieser Web-API keine direkte Schnittstelle, die du nutzen kannst?

wie mach ich das ?

Im entsprechenden Skript das zu der aufgerufenen Ressource gehört -- in PHP mit der Funktion header.

[wahsaga]

Zugriff auf die API hab ich nur von meiner Server IP.

Das klingt nach einem bewusst implementierten Sicherheits-Feature ...

Aber so kann ich die Api auch von anderen IPs nutzen.

... welches du mit deinem „Proxy-Script” unterlaufen willst.

Aber nachzufragen, ob du dir das auch wirklich gut überlegt hast, dürfte vermutlich mal wieder sinnlos sein ...?

[JR-EWING]

Hi Wahsaga,

Das klingt nach einem bewusst implementierten Sicherheits-Feature ...

Bitte verstehe, dass ich nicht meine ganze Architektur aufzeigen möchte und den Sinn meines Scriptes hier aufführen will. Es würde mir ja nicht weiterhelfen, dass momentane Problem zu lösen. Das angedeutete Sichheitsfeature ist von mir selber implementiert. Es dient zum Austausch von Datenbank inhalten die ich nur zentral an einer Stelle halte. Deswegen kommt man nicht extern auf die DB und nur über die API kann man z.B. Daten einfügen. Durch curl_multi dachte ich es geht schneller und ich kann das parallel abfragen.
Ich versteh bloß nicht warum bei mir der Curl Multi so lange dauert während sequenziell es deutlich schneller geht.

Das setzen von Header Connection Close in meinem Proxy Script hat leider keine Besserung gebracht.

[AmicaNoctis]

Ich frage mich trotzdem noch, warum du – gerade wenn du es selbst implementiert hast – über eine Web-API darauf zugreifst und nicht direkt im Skript. In welcher Programmiersprache ist es denn geschrieben? In PHP? Dann kannst du doch genausogut die entsprechende Klasse direkt im Code instanziieren und benutzen, statt einen Loopback-Request zu erzeugen. Wenn du bei jeder Anfrage eines Clients 30 weitere Anfragen erzeugst, verbrauchst du nur massig Ressourcen.

Wenn du nicht weiter darauf eingehen kannst, verstehe ich das, aber trotzdem sieht das für mich nach einem üblen Designfehler aus, solange keine triftigen Gründe für diesen Ansatz erkennbar sind.

[onemorenerd]

Zugriff auf die API hab ich nur von meiner Server IP.

Über HTTP!?!

Ich kannte mal einen, der hat die PIN für seine EC-Karte in eine Datei auf einem Server im Internet gespeichert, um sie nicht zu vergessen. Damit aber nicht jeder Hans Wurst seine PIN sehen konnte, hat er sie mit einer Passwortabfrage vernagelt. Rate mal was das Passwort war!

[AmicaNoctis]

rate mal was das passwort war!

123456?

[onemorenerd]

Völlig egal welches Passwort! Der Witz ist doch, dass er sich nun ein Passwort merken musste, um an seine PIN zu kommen, die er sich nicht mehr merken musste.

Der TO hat seine DB hinter einer API versteckt, um die Operationen auf und mit der DB kontrollieren zu können. Die API wird über ein Netzwerkprotokoll benutzt. Damit nicht jeder Hans Wurst die kontrollierten Operationen ausführen kann, ist der Zugriff auf localhost beschränkt.
Er hat also
- eine DB,
- eine API auf localhost, die mit der DB spricht
- ein Script auf localhost, das mit der API auf localhost spricht

Preisfrage: Was hindert das Script daran, direkt zur DB zu connecten so wie es die API macht?
Vermutlich genau so wenig wie den EC-Kartenbesitzer daran gehindert hat, seine PIN als Passwort zu wählen.

Beiden gemeinsam ist, dass das eigentliche Problem (Merkzwang bzw. Sicherheit/Kontrolle) auf dem jeweiligen Weg (Passwort bzw. API) gar nicht gelöst wurde.

[JR-EWING]

ja jetzt wissen wir alle, dass ich ein ganz mieser Softwaredesigner bin.

Preisfrage: Was hindert das Script daran, direkt zur DB zu connecten so wie es die API macht?

Bei mir ist es halt nicht die gleiche IP obwohls der gleiche Server ist. Aber egal.



Wäre dankbar wenn jemand noch einen Tipp hätte woran es liegen könnte, dass ich innerhalb eines Servers so einen Zeitverlust bei Curl Multi habe.



gruß Tom

[unset]

Das kann so viele verschiedene Ursachen haben wie du Bibliotheken auf einem Server installiert hast. Das ist übrigens kein Vergleich, sondern eine konkrete Aussage: Um eine Antwort auf deine Frage zu erhalten, bleibt dir nichts anderes übrig als deine komplette Serverkonfiguration Preis zu geben. Aber wenn du schon Bedenken hast, uns den Sinn einer –*wie von onemorenerd ja ausführlich erläuterten – sinnlosen Architektur zu nennen, wird dir das sicherlich die Schuhe ausziehen.

[onemorenerd]

Bei mir ist es halt nicht die gleiche IP obwohls der gleiche Server ist.

Was hat das damit zu tun?

Der Mehrwert von Multi-cURL ist übrigens nicht nur das parallele Ausführen der Requests sondern auch, dass es non-blocking parallel zum PHP-Script läuft. Daher ist nicht sehr sinnvoll, die Gesamtlaufzeit alles Requests zu messen. Du solltest nur die Zeit erfassen, die du wirklich auf cURL warten musst.

Die unterschiedliche Performance auf unterschiedlichen Plattformen kann viele Ursachen haben, z.B. Lib-Version, PHP-Version, DNS-Performance, DNS-Caches, ...

Generell sollte sequentielles cURLing ab einer nennenswerten Zahl von Anfragen niemals schneller sein als multi-threaded cURLing. Wenn das bei dir so ist, liegt es wahrscheinlich an deinen Messmethoden.