Wer nutzt denn alles DataSnap?

[himitsu]

Eigentlich wollten wir im ersten Schritt unser Dateimanagement auf Basis vom Datasnap auslagern, aber so wie es aussieht, ist das ja arschlangsam.
selbst wenn Server/Client auf dem selben Rechner direkt nebeneinander laufen, dann bekomm ich, via TCP/IP auf localhost, effektiv grade mal nur 1 MB/s raus.

Übers Netztwerk konnte ich jetzt leider noch nicht direkt testen, aber dort erwarte ich dann noch weniger.

[Daniel]

Welche Geschwindigkeiten bekommst Du denn in Eurem System, wenn Du die Dateien direkt via TCP/IP (z.B. mittels INDY) überträgst?
Sprich: Über welche Verzögerung durch DataSnap reden wir?

[himitsu]

TIdTCPServer/Client
5.000.000 Byte in 47 Milisekunden


DataSnap
2.251.872 Byte, nach Umwandlung in Base64 vielleicht 3 MB in 2,5 bis 3 Sekunden (knapp 150-200 ms sind dabei mein eigener Code)

[Phoenix]

Zitat von himitsu:

Eigentlich wollten wir im ersten Schritt unser Dateimanagement auf Basis vom Datasnap auslagern, aber so wie es aussieht, ist das ja arschlangsam.
selbst wenn Server/Client auf dem selben Rechner direkt nebeneinander laufen, dann bekomm ich, via TCP/IP auf localhost, effektiv grade mal nur 1 MB/s raus

Sowas ähnliches wurde auf Basis von RO/SDK schonmal umgesetzt: Case Study, Shell+ and Documents. Da gibts auch Beispiel-Sourcen dazu. Und von der Performance her ist das alles andere als langsam

[himitsu]

Nun sind wir ja fast fertig, aber wenn's so weitergeht, dann laufe ich auch über.

PS:
Endlich mal einer, der meine Probleme kennt
http://cc.embarcadero.com/item/27391
darin hab ich z.B. etwas gefunden, ala "große Streams übertragen" und so wie es aussieht, hatte er in etwa die selbe Idee, um das Problem zu lösen.

Aber wie bei vielen anderen Codes (auch die von Dr. Bob) bin ich mir sicher, daß er nicht nach Speicherlecks ausschau gehalten hat.

Dr.Bob hat wenigstens fast nur die versteckten Speicherlecks übersehn, aber das sowas hier ist ja wohl eindeutig:

Delphi-Quellcode:

procedure TFrmMain.Button4Click(Sender: TObject);
var
  Sm: TDSServerMethodsClient;
begin
  Sm := TDSServerMethodsClient.Create
    (DMClientContainer.MyDSServer.DBXConnection);
  LBDateTime.Caption := DateTimeToStr(Sm.GetServerDateTime);
end;
// Sm wird jedesmal neu erstellt und nie freigegeben

procedure TFrmMain.Button9Click(Sender: TObject);
begin
  Result := TJSONFalse.Create;
  ...
  for i := 0 to LJSONObject.Size - 1 do
  begin
    ...
    Result := TJSONTrue.Create;  // wird immer wieder neu erstellt
  end;
  ...
end;

Da findet man schon fast nirgendwo ordentlich Hilfe, bei diesem suuuuuuper Produkt Namens DataSnap und wenn, dann muß man erstmal die Fehler beheben.

Nichts gegen diese Leute persönlich, aber wenn das wirklich jemand ernsthaft einsetzen würde, dann wären doch viele Fehler schon längst aufgefallen, oder meint ihr nicht.
Wobei hier vermutlich der Garbage Collector im C#, PHP, Java oder wo DataSnap noch nutzbar ist, vermutlich derartige Speicherlecks behebt.

Auch wenn die Grundidee vom DataSnap ja garnicht mal soooooo schlecht ist.

[stahli]

Gibt es aktuelle Erfahrungen?

[himitsu]

Zitat von stahli:

Gibt es aktuelle Erfahrungen?

Bezüglich was genau?

> DataSnap ist recht langsam, vorallem wenn man auch mal größere Datenmengen übertragen will
> Stream-Parameter ab standardmäßig 29 KB (maximal 64 KB - 1 = Word) werden einfach nicht übertragen
> größere Stringparameter gehen aber (wenn auch noch langsamer)
> wenn man größere Datenmengen übertägt, steigt die CPU-Belastung schonmal ungewöhnlich stark an
> Nahezu alle Beispielcodes sind fehlerhaft, vorallem die wo JSON verwendet wird
(gut, eigentlich stammen fast alle diese speicherleckigen Codes von Dr. Bob und viele andere, der wenigen "selbsternannten DataSnap-Experten" kopieren eigentlich nur von ihm)

[stahli]

Zitat von himitsu:

Bezüglich was genau?

Ganz allgemeiner Art. Hätte nur mal gern auch etwas positives gelesen...

[jaenicke]

Das mit den Beispielcodes ist so eine Sache, man kann daran erkennen was da alles möglich ist. Wenn man das dann selbst umsetzt, ist das im Grunde kein Problem. Ganz ohne die Beispiele hätte ich sicher länger gebraucht...

Wir haben damit mittlerweile einiges gemacht und planen noch sehr viel mehr damit. Es gibt zwar immer mal wieder kleine Stolperstellen, aber bisher nichts wo wir nicht weitergekommen wären. Das funktioniert soweit ganz gut.

Das einzige wo wir noch nicht so sicher sind, ob unsere Lösungsansätze wirklich stabil laufen, ist das Management bei Verbindungsabbrüchen. Denn da habe ich in XE nicht wirklich viel dazu gefunden, ist aber für die intensiv genutzten Callbacks, auch bei Thin Clients, sehr wichtig.

[himitsu]

So im Großen und Ganzen isses schon nutzbar.

Bei den Verbindungsabbrüchen bin ich auch ins stocken geraten.
Theoretisch enthält DataSnap ein OnDisconnect, wo man notfalls versuchen könnte die Verbindung neu aufzubauen.
Nur ist es so, daß DataSnap manchmal garnicht mitbekommt, daß die Verbindung weg ist und dann dieses OnDisconnect nie aufruft ... gibt dann nur beim nächsten Versuch eine Servermethode aufzurufen eine schöne Exception.
Das liegt aber vermutlich eher am intern genutzen DBExpress, denn da kann man die DBConnection auch fragen, was man will, selber bei einem Verbindungsabbruch ist dessen Connected gerne mal True und auch regelmäßige .Connect aufzurufen bringt nichts, da DBX ja denkt es sei noch verbunden.
Am Ende zählen wir jetzt quasi die Verbindungsprobleme und führen dementsprechend abundzu mal ein Disconnect+Connect auf.

PS: Man kann DBX zwar ein Timeout mitgeben, aber wenn der Server mal Probleme hat, dann wird dieses ganz gekonnt ignoriert und auch der Client bleibt dann einfach hängen.
Unsere schnelle etwas unschöne Lösung > die Methodenaufrufe werden jeweils in einen Thread ausgelagert, welcher nach paar Sekunden einfach links liegen gelassen wird.