RemObjects vs. RealThinClient

[Bentissimo]

Hallo zusammen,

in einem schon etwas länger zurück liegenden Projekt (Delphi 5!) hatte ich noch die Komponenten TClientSocket und TServerSocket verwendet.

Das bzw. die Programme liefen zwar zufriedenstellend aber leider nicht mehr als das. In Zukunft möchte ich für Projekte, die Verbindungen in jedweder Form über TCP/IP herstellen, gerüstet sein und nur noch absolut professionelle Komponenten bzw. Lösungen einsetzen.

Natürlich sind die Indys eine deutlich bessere Wahl als die obigen Socket-Komponenten, doch nach Lesen dieses Blogs kommen mir hinsichtlich der Qualität auch da meine Zweifel.

Dies soll aber keinesfalls ein Bashing gegen die Indys werden. Nur gibt es wahrscheinlich noch bessere Lösungen und genau die möchte ich gerne finden und gegebenenfalls einsetzen.

Eine Recherche bringt eigentlich immer die beiden Protagonisten RemObjects und RealThinClient hervor und nachdem hier im Forum seit kurzem ausführlich über RemObjects DataAbstract diskutiert wird, hielt ich die Zeit für gekommen, um mein Thema einzubringen.

Hat jemand Erfahrung mit der einen oder anderen oder gar beiden Bibliotheken? Lässt sich ein Qualitätsunterschied feststellen? Auch gegenüber den Indys? Oder womöglich sogar ein "klarer Sieger"?

Würde mich über jede Meinung freuen.

Vielen Dank & viele Grüsse!

Stephan

[mjustin]

Zitat von Bentissimo:

Natürlich sind die Indys eine deutlich bessere Wahl als die obigen Socket-Komponenten, doch nach Lesen dieses Blogs kommen mir hinsichtlich der Qualität auch da meine Zweifel.

Die Performance der Indy HTTP Server Komponente ist nach meinen Tests eigentlich nicht schlecht.

Ich habe heute einen Test mit dem Indy HTTP Server auf sehr viel langsamer Hardware gemacht (Mobile Core 2 Duo statt Core i5 mit 4 CPUs), und erhielt 320 Requests pro Sekunde als kontinuierlichen Durchsatz. Dabei habe ich sowohl den Client (das Apache JMeter Testskript, das die Last erzeugte) als auch den Indy HTTP Server auf der gleichen Maschine ausgeführt.

DataSnap über Indy schaffte im Test von Roberto Schneiders nur 62 Requests/Sekunde. Aber es wird laut Kommentaren im Blog schon untersucht, woher diese niedrigen Durchsatzwerte bei DataSnap kommen.

p.s. Ich fände einen Performancetest anderer Web Service Frameworks (RO und RTC) auch recht interessant.

p.p.s.:

Screenshot: mit 50 Threads (ebenfalls JMeter Clients und Server auf der gleichen Hardware laufend) schafft Indy HTTP Server ca. 1400 Requests pro Sekunde, mit 50% CPU Last und 3 MB RAM auf meinem relativ langsamen System.

[Bentissimo]

Also zumindest RTC hat die Ergebnisse eines solchen Stresstests mit den eigenen Komponenten veröffentlicht.

Sieht beeindruckend aus.

Allerdings bin ich (noch) zu wenig bewandert hinsichtlich der beiden Sammlungen, so dass ich mir kein Urteil erlauben kann.

Aber genau deshalb hab ich ja diesen Thread gestartet.

[mjustin]

Zitat von Bentissimo:

Also zumindest RTC hat die Ergebnisse eines solchen Stresstests mit den eigenen Komponenten veröffentlicht.

Sieht beeindruckend aus.

Der Test zeigte auf jeden Fall dass RTC sehr stabil läuft und mit hohen Connectionzahlen gut umgehen kann.

Aber der Durchsatz (Requests pro Sekunde) und die Antwortzeit sind nicht besonders hoch. Der Client musste im Durchschnitt ca. 15 Sekunden auf die Serverantwort warten:

* 394.000.000 Requests in einer Woche entsprechen 651,5 Requests pro Sekunde
* bei 9.900 Connections ergibt sich eine Antwortzeit von 9.900 / 651,5 = gut 15 Sekunden

Im Vergleich dazu Node.js, das langsamste, JavaScript basierte Framework im Test von Roberto Schneider:

* 16.000 Requests/Sekunde
* bei 100 Connections ergibt sich eine Antwortzeit von 6,25 Millisekunden

Die Tests sind aber nicht direkt vergleichbar, da unterschiedliche Hardware eingesetzt wurde, und RTC mit SSL Verschlüsselung arbeitete.

[taveuni]

Imho kann man RealThinClient nicht mit Remobjects vergleichen.
Wir setzen RealThinClient für eine eigene "Remotedesktop" Lösung ein -
was einigermassen funktioniert.

Remobjects aber ist ein Framework ohne welches wir uns nicht mehr vorstellen könnten
Multi-Tier Applikationen zu erstellen. Und dies auch mehr und mehr zwischen verschiedenen
Platformen und/oder Programmiersprachen.

Es nimmt dir die gesamte Kommunikation sowie das Protokoll ab. Du definierst Methoden und
Strukturen welche auf dem Client oder Server aufgerufen und übergeben werden. Auf der anderen
Seite genau gleich.

Die Performance ist ausschliesslich abhängig von der Umgebung. Für die einzelnen Channels können
sogar die darunterliegenden (Socket-)Frameworks gewählt werden (Indy, ICS, Synapse usw.).
Lade Dir einfach die Trial herunter und spiel damit herum.

[mjustin]

Zitat von taveuni:

Remobjects aber ist ein Framework ohne welches wir uns nicht mehr vorstellen könnten
Multi-Tier Applikationen zu erstellen. Und dies auch mehr und mehr zwischen verschiedenen
Platformen und/oder Programmiersprachen.

Es nimmt dir die gesamte Kommunikation sowie das Protokoll ab. Du definierst Methoden und
Strukturen welche auf dem Client oder Server aufgerufen und übergeben werden.

Auf Roberto Schneiders Blogseite ("DataSnap analysis based on Speed & Stability tests") wurde heute in einem Kommentar dargestellt, dass dieses Framework keine REST Unterstützung bietet (nach Angaben des RemObjects Support). Daher wurde es im Vergleich zwischen DataSnap, WCF, mORMot, Grizzly/Jersey und Node.js auch nicht berücksichtigt. Tests zeigten laut Roberto Schneiders, dass es eher noch schlechtere Performance zeigte als DataSnap (was aber eventuell mit Optimierungs'kniffen') verbessert werden kann).

REST ist wegen seiner leichtgewichtigen Architektur beliebt, die auch die Erstellung von Clients vereinfacht (man braucht nur eine HTTP Bibliothek).

RemObjects und DataSnap sind funktional mächtiger, aber auch "etwas" schwergewichtig. Dass bei DataSnap für jeden Request standardmäßig eine neue Session erzeugt wird (es sei denn, der Client sendet eine Session-ID im Request mit), ist ein Nachteil gegenüber Frameworks die neben sessionorientierter Arebitsweise auch eine rein requestbasierte Verarbeitung anbieten. Es wurde schon vorgeschlagen, die Kommunikationsschicht von DataSnap komplett neu zu bauen, und dann auf eine leistungsfähigere Architektur wie I/O Completion Ports (lockfrei) umzustellen. Das könnte die Anzahl Clients eines DataSnap-Servers um einen Faktor zehn bis tausend hochschrauben.