fopen od. CURL?

[da_chris]

Hallo,

habe ein Script das via HTTPs API und fopen auf eine externe Seite Werte übermittelt.

Das Problem ist jedoch das hier dann das Laden der Bestätigungsseite ca. 2-7 Sekunden dauert, je nach Auslastung.

Ich habe mal den Tipp erhalten auf CURL umzusteigen, anstatt fopen. Doch hier ist die Frage welche Vorteile CURL bringt?

Sicherheit und/oder Geschwindigkeit? Habe schon gegoogelt, aber nichts sinnvolles gefunden.

Danke,

Chris

[penizillin]

welche Vorteile CURL bringt? ... Sicherheit und/oder Geschwindigkeit?

teste doch mal das zweitere..

aber auf jeden fall eine menge fertiger funktionen und einstellungen - s. manual.

[hhcm]

Quelle turotials.de (Google 2ter Treffer... )


Vorteile:
Die Curl - Technologie hat ein Reihe von Vorteilen, die sich direkt aus den Curl speziefischen Features ergeben.
Als erstes wäre der Performancegewinn zu nennen. Dank Curl erreiche ich einen effizienteren (schnelleren) Download der Seite. Eine 50 kB HTML-Seite lässt sich als 5 kB Curl-Seite darstellen.
Das lässt sich vor allem durch den Ersatz von Grafiken durch prozedurale Grafiken erklären. Dadurch wird der Server schon mal entlasten.
An dieser Stelle kommt jetzt die clientseitige Ausführung in Spiel. Im Gegensatz zu HTML brauche ich die Daten nur einmal herunterladen. Ein Beispiel: Eine Suchmachine gibt mir eine gewisse Anzahl, z.B. 20, an Treffern auf eine Suchanfrage zurück. Bei den meisten Suchmaschinen kann man einstellen wie viele Treffer man auf einer Seite angezeigt bekommen möchte. Stelle ich jetzt von z.B. 20 Treffern pro Seite auf 10 herunter, muss ich bei einer herkömmlichen HTML erst wieder den Umweg über den Server machen. Es wird eine komplett neue Webseite zurückgegeben, wir erinnern uns nochmal 50 kB. Curl setzt gerade bei solchen Anwendungen auf den Client-Rechner. Die Sortierung oder die Anzahl der angezeigten Treffer wird clientseitig ausgeführt. Bei HTML sind wir an dieser Stelle schon bei 100 kB, Curl immer noch 5 kB.
Also noch mal auf den Punkt gebracht: Die Daten werden einmal vom Server heruntergeladen, Darstellung und Reaktion auf Benutzereingaben (natürlich mit Ausnahme einer neuen Suchanfrage, um bei unserem Beispiel zu bleiben) laufen komplett clientseitig ab. Das entlastet den Server noch weiter. Hoster werden sich freuen.
Das bringt ganz offensichtlich weitere Vorteile wie höhere Interaktivität einer Webseite, oder besser Webapplikation. Auf den Server muss ich warten. Nicht umsonst wird zum WWW scherzhaft world wide waiting gesagt. Mit Curl hingegen kann ich mit Webseiten mit der Performance einer normalen Windows-Applikation z.B. Word interagieren !
Für den Benutzer also ein eindeutige Vorteil. Schon mal zwei (neben den Hostern). Doch auch die dritte beteiligte Gruppe - die Webdesigner - dürften Vorteile genießen. In letzten Abschnitt haben wir gesehen, was die Sprache Curl alles beherrscht, von Mark - up über Objektorientierung bis zu Grafik und alles mit einer Sprache. Betrachten wir uns hingegen die klassische Webseite von heute: HTML, CSS, JavaScript, DHTML, PHP / Perl / ASP / Java und Flash. Erscheint es bei diesem Patchwork von Techniken, welches ja zwangsläufig zu irgendwelchen Schnittstellenproblemen kommen muss, nicht besser eine einzige Technik zu verwenden, die weite Teile der eben genannten Techniken abdeckt zu benutzen. Durch die Verwendung einer einzigen Sprache erreiche ich auf jeden Fall eine bessere Erweiterbarkeit der Webseite. Außerdem dürfte sich die Entwicklungsproduktivität steigern - ich brauche halt nur Programmierer für eine Sprache. Weiterhin dürfte die Entwicklung mit nur einer Sprache schneller und übersichtlicher sein.

Ausblick:


Ein weitere wichtige Punkt in Bezug auf Curl ist die Kompatibilität zu bestehenden Technologien wie HTML oder CGI. Man kann Curl - Applets (das was ich bisher als Curl - Webseite oder Curl - Webapplikation bezeichnet habe) in HTML-Seiten einbinden oder ein CGI - Skript (Common Gateway Interface) auf dem Server aufrufen. Bespiele dazu folgen im Kapitel Was kann ich mit Curl machen ?. Die Kompatibilität sicherzustellen ist vor allem für die Phase wichtig in der Curl sich jetzt gerade befindet. Dadurch kann der Webdesigner von heute erst mal spezielle Teilbereiche seiner Webseite auf Curl umstellen und muss sich nicht sofort komplett umstellen, denkbar wären auch Startseiten auf denen man zwischen HTML und Curl wählen kann, wie es für HTML und Flash ja bereits gängig ist. Notwendig ist es da Curl genau wie Flash eine Plugin - Technologie ist. Doch dazu mehr im nächsten Kapitel.
Die erste offizielle Version von Curl erschien erst im November letzten Jahres, ist also noch sehr jung. Längst noch nicht alle geplanten Features sind in der Sprache integriert, noch nicht alle Rahmenbedingungen für einen breiten Einsatz von Curl geschaffen. Als neue Sprachfeatures hat z.B. XML - Support eine hohe Priorität. SAX2 (Simple API for XML), SOAP sind bereits integriert. DOM (Document Object Model) soll folgen. Weiterhin soll Curl vom Browser alleine losgelöst werden, es soll möglich sein Curl -Applikationen oder Curl - Skripte (die z.B. auf Webservern laufen) zu erstellen. Multithreading, als weiteres Stichwort.
Wichtig, wenn nicht sogar wichtiger sind die allgemeinen Rahmenbedingungen, die Curl zum Erfolg verhelfen können. Auch da möchte die Curl Corporation nichts dem Zufall überlassen. Multi - platform support steht wohl an zentraler Stelle. Derzeit ist die offizielle Curl - Version nur für Windows verfügbar, für Linux ist sie im Beta-Test. Curl soll jedoch auch für Mac, PDA und Handys entwickelt werden. Auch Curl predigt "write once, run everywhere". Mal sehen, ob sie es hinbekommen !
Weiterhin soll ab erstem Quartal 2002 ein Open Source - Projekt gestartet werden. In wie weit der Curl - Quellcode freigegeben werden soll, ist (mir) derzeit nicht bekannt. Ansonsten ist es das Ziel allgemeine Standards (z.B. DOM) in die Sprache zu integrieren und keine eigenen zu kreieren.

[da_chris]

Was für eine Möglichkeit habe ich eigentlich via fopen das er die Parameter übermittelt ohne das der Besucher meiner Seite 2-7 Sekunden lang warten muss?

Sprich, das das ganze im Huntergrund abläuft ohne das der Benutzer Wartezeit hat.

[TBT]

Hi,

ich lade bei einem meiner Projekte auch ständig Daten von einem anderen Server per https nach. Nur kann ich da keinerlei Verzögerung spüren. Wo kommen denn deine 5-7 Sek. her? Ist der andere Server eventuell überlastet?


PS: der schlimmste Fall bei meinem Projekt, ist eine Übersichtstabelle, mit 25 Zeilen. Dabei lädt er die Tabellendaten vom anderen Server (1 https Aufruf), sowie pro Zeile noch 3 weitere Aufrufe. Gesamtzahl der https Anforderungen liegt dann bei 76 Aufrufen, und er hat noch nie länger als 2 Sek dafür gebraucht.

mein allgemeiner Aufbau:

1 User will Seite von Webserver sehen
2 das PHP Script auf dem Webserver öffnet eine https Verbindung zum Gateway
3 das Gateway schleift die Verbindung zum internen Server weiter
4 der interne Server anwortet auf die https Anfrage
5 Daten zurück über das Gateway zum Webserver
6 Auswertung der erhaltenen Daten durch das PHP Script auf dem Webserver
7 Auslieferung der Webseite an den User

Punkt 2 bis 6 werden pro https Anfrage wiederholt

[da_chris]

Nun, das ganze ist ein Script für den SMS-Versand.
Der Server ist nicht wirklich überlastet.
Es schaut dumm aus da er - bis er Rückmeldung vom Fremd-Server erhält - meine Seite nur zur Hälte aufbaut.

Ich habe damals schon versucht das ganze mittels SMTP hinzukriegen, was auch funktionierte. Problem ist das er hier für den SMS-Versand rund 2-5 Sekunden länger braucht. Wenn`s dann wieder mal ein Problem mit dem SMS-Gateway SMTP System gibt dauert noch länger.

Daher bin ich auf HTTP API umgestiegen, welches mit fopen arbeitet.
Ich will das ganze allerdings komfortabler machen. Auch wenn`s nur 2 Sekunden Wartezeit kommt man sich auf der Seite wie gelähmt vor, vor allem wenn der Seitenaufbau während der Übermittlung so stark zusammenbricht.

Deshalb war meine Überlegung auf CURL umzusteigen, weil mir damals jemand dazu geraten hat. Leider weiß ich über CURL nicht sehr viel.

[pekka]

Wenn das SMS-Gateway so langsam ist, kannst Du so viel curlen, wie Du willst! Bringen wird das nix... Ich würde die Bestätigungsseite unabhängig vom Gateway aufbauen und den Status (gesendet / nicht gesendet) in einem kleinen IFrame anzeigen. Dann sieht es nicht so schlimm aus.
Dir ist klar, daß Du, wenn Du gar keine Rückmeldung vom Gateway brauchst, den entsprechenden Aufruf in ein eigenes Skript auslagern und im Hintergrund ausführen kannst?

[da_chris]

Wie übergebe ich dann die "Arbeit" an ein anderes Script?
Genau das wäre eine Lösung die ich haben will.

Rückmeldung brauche ich keine. "Die Nachricht wurde versendet" erscheint so oder so immer, es gab in den 8 Monaten in denen ich das Gateway verwende noch keinen einzigen Connect-Fehler.

[pekka]

In den User-Contributed Notes zu exec() findest Du viele Anregungen. Bei mir funktioniert das hier gut:

I made my script work in the background like this:

function start_shell ($cmd) {
   exec('nohup "'.$cmd.'" > /dev/null &');
} 

[penizillin]

auch gerade eben entdeckt - könnte evtl. helfen:
http://de.php.net/manual/de/function...imit.php#53564