Http Get (aber bitte schnell)

[Phoenix]

Okay, mir fehlen hier grundlegende Informationen um auch nur Ansatzweise raten zu können, an was es liegen könnte.

1.) Welches Format fährst Du über REST?
REST kann prinzipiell mal alles rüberschicken. HTML, JSON, auch XML oder CSV sind grundsätzlich möglich. Was nutzt Du konkret?

2.) Wie sieht das aus, wenn Du mal mit konstanten, nicht berechneten Werten arbeitest?
Also konkret, entweder mit Fiddler das Ergebnis cachen oder noch einfacher, das Ergebnis des REST-Calls durch den Browser abrufen, in eine Datei speichern und dann diese als statisches File auf eine andere URI legen, die Du dann über Deinen REST Client abrufst. Damit kannst Du eine konstante, sehr kleine Abrufzeit erreichen, die Deine Messung nicht beeinflusst.

3.) Schneide mal den Traffic zwischen Deinem Client und der Service mit Fiddler mit. Vielleicht bekommst Du hier einige zusätzliche Informationen was hier passiert.

Ich würde ohne diese Infos vermutlich darauf tippen, das hier JSON über die Leitung fliegt und der Teil der das JSON parsed nicht ganz so performant ist, wie eine XML deserialization.
Vielleicht kannst Du mit einem simplen Tweak das Ausgabeformat des Service auf XML forcieren (sollte bei WCF mit einem URL-Parameter gehen), und damit könntest Du ggf. in den Genuss der schnelleren XML-Deserialisierung kommen ohne von REST weg zu müssen. Aber wie gesagt: Ist nur geraten, ohne ausreichend Informationen zu haben.

[cherry]

Hallo Phoenix

Was kann denn noch fehlen. Ich hab ein minimales Projekt angehängt wo der Fehler zu reproduzieren ist. Zumindest bei mir. Wäre eben interessant ob das bei andern auch so ist.

1) GET anfrage. Rückgabe ASCII String (Das hab ich oben schon erwähnt). Kein JSON kein XML.
2) In meine Beispielprojekt wird die Messung nicht gross durch Berechnungen beeinflusst. Die "Berechnungszeigen" des Servers werden geloggt und sind mehr oder weniger Konstant. Ich habe im Beispielprojekt ein Sleep von 500 ms eingebaut. Das Erstellen von 1000 Random IDs kostet fast nichts. Trotzdem dauert die Anfrage über REST Zeitweise 0.5s Länger als erwartet!
3) Mit TcpTrace sehe ich den Verkehr und das sieht soweit gut aus. Mit Fiddler ists in der Tat komisch... SOAP Variante sehe ich... REST Anfrage über Browser sehe ich auch. In Fiddler tut sich aber rein gar nichts, wenn ich eine REST Anfrage über den Delphi7 Client verschicke. Der Webservice wird aufgerufen, ich erhalte ein Resultat, aber Fiddler sieht nichts?! (TcpTrace siehts, logischerweise). Fiddler kenn ich halt auch zu wenig, keine Ahnung warum ers nicht sieht...

Wenn nicht noch jemand eine Zündende Idee oder ein schwerwiegenden Verdacht hat, werde ich hier aufgeben und mich für die SOAP Variante entscheiden müssen. Ansonsten komme ich hier nie weiter. Wäre toll wenn jemand noch mein Beispiel Programm anschauen könnte, vielleicht sieht ihr da was ???

[Lemmy]

Win7 Prof, virtualisiert mit 10 GByte RAM auf einem iCore7

REST: Erstaufruf >1000 ms, restliche Aufrufe zwischen 500 ms und 550 ms
Soap: Erstaufruf >1000 ms, restliche Aufrufe zwischen 650 ms und 700 ms


jeweils ca. 10 Aufrufe


Antivirus: Bitdefender AV Plus 2013 deaktiviert:

alle Aufrufe (Soap und Rest) ca. 20-30 ms schneller

Tipp: Schalte mal deinen AV aus und schau dann ob du noch die großen Differenzen hast...

[Phoenix]

Zitat von cherry:

Fiddler kenn ich halt auch zu wenig, keine Ahnung warum ers nicht sieht...

Fiddler ist ein Proxy. Das heisst wenn Indy die Browser-Proxy-Config nicht berücksichtigt, müsstest Du dem Indy client noch sagen benutze bitte den Proxy auf localhost, Port 8888 (default).
Danach solltest Du den Request da durchhuschen sehen.

Der angesprochene Virenscanner könnte allerdings tatsächlich eine Bremse sein.

[cherry]

So. Hab nun den Delphi Client so erweitert, dass der Rest Service auch direkt über Sockets angesprochen wird (Anstatt TIdHttp Komponente o.ä). Nun bringt das ganze leider auch keine Verbesserung die Anfragezeiten verhalten sich gleich wie mit der TIdHttp Komponente...

Ich schnalls echt nicht, wie der Browser ("Advanced Rest Client" App für Chrome) hier schneller sein kann?! Das Verhalten ist völlig unterschiedlich. Obwohl ich zum Testen sogar genau denselben HTTP Header verwendet habe. Der Server sollte daher die Anfragen genau gleich behandeln...

Werde das gleich mal prüfen mit dem Virenschutz...

@Lemmy Danke fürs Testen. Interessant, bei dir verhält es sich ja so, wie ich mir das Ursprünglich vorgestellt habe. Vorallem treten bei dir keine Schwankungen auf mit der REST Variante, sehr interessant...

[cherry]

Also wenn ich das ganze auf einem anderen Rechner (ohne Virenschutz) laufen lasse, dann funktionierts tatsächlich. Keine Schwankungen mehr und REST ist wie erwartet etwas schneller. Hab allerdings noch nicht herausgefunden, warum es auf meinem Rechner nicht geht (ausschalten des Virenschutzes bringt leider nichts).

In diesem Sinne liegt das Problem also weder beim Server noch beim Client, sondern irgendwo dazwischen. Probiere das Problem bei Gelegenheit noch genauer ausfindig zu machen. Eine Frage bleibt allerdings im Moment noch offen:

- Warum betrifft es nur die Delphi REST Variante (weder SOAP noch Browser REST) haben hier ein Problem ?

Vielleicht ergibt das einen Sinn, wenn ich herausgefunden habe, was hier dazwischenfunkt...

[mkinzler]

Viele Virenscanner/Firewalls transpaltieren sich derart tief ins System, so daß eine einfache Deaktivierung oft nichts mehr bringt.

[Uwe Raabe]

Zitat von mkinzler:

Viele Virenscanner/Firewalls transpaltieren sich derart tief ins System, so daß eine einfache Deaktivierung oft nichts mehr bringt.

Das grenzt dann aber schon hart an Malware.

[mkinzler]

Ist aber imho gängige Praxis.