RemObjects vs. RealThinClient

[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.