[JAVA] RMI performance

[Verwijderd]

Wie o wie heeft ooit eens wat tests gedaan/gezien naar de performance van RMI tov vergelijkbare oplossingen (Java/C++ sockets, CORBA, DCOM)?? Ben namelijk erg beniewd en kan er zo gauw niets over vinden op het net. De enige twee goede links die ik tot nu toe heb zijn:

Java alternatieven, maar hier wordt dus RMI alleen vergeleken met andere Java alternatieven, terwijl het natuurlijk veel informatiever was geweest als hij ook even een C++ programma mee had genomen in de test. Uit zijn tests blijkt trouwens dat RMI performance praktisch hetzelfde is als een eigen Java socket implementatie. Zijn er meer mensen met soortgelijke ervaringen??

RMI optimizen is een hele andere pagina met info over hoe je RMI zo veel mogelijk kan tweaken.

Ik wil binnenkort zelf even wat test progsels gaan schrijven maar heb daar de komende dagen nog even geen tijd voor en als iemand anders al een mooie tabel heeft liggen...

Er zijn trouwens behoorlijk wat pagina's die RMI helemaal afbranden als het om performance gaat, maar die komen nergens met harde meetgegevens, k zet er dus zo mn vraagtekens bij...

[Alarmnummer]

[spam]
anders moet je dit topic ook even op http://www.javahova.net plaatsen. Daar zijn ook een hele lading java programmeurs.
[/spam]

[The - DDD]

RMI is een remote invocatie verhaal. En die afbrand verhalen zijn nogal vaag geschreven aan de hand van een toepassing die niet echt representatief is. Netwerk verkeer heeft zowiezo een behoorlijk trage doorvoer.

Let er ook op dat je RMI kan gebruiken met JRMP en IIOP. Twee verschillende protocollen. Leuke van IIOP is dat het CORBA compatible is, nadeel is dat het wat meer low-level is. JRMP heeft leuke features als remote garbage collection en nog wat zaken.

En verder, links? Sja, geen idee...

Edit: Let ook op de publicatie datum van de stukken die je leest. Ik check net even op google en ik zie bij de afbrand verhalen nogal vaak jaartallen tussen 1996 en 2000 voorbij komen. De 1.3 JDK heeft op performance gebied heel wat verbeteringen gebracht.

[Verwijderd]

Op woensdag 10 april 2002 09:30 schreef The - DDD het volgende:
Netwerk verkeer heeft zowiezo een behoorlijk trage doorvoer.

Das logisch maar daar hebben alle alternatieven natuurlijk last van... (gewone methode aanroepen zijn geen alternatief)

Let er ook op dat je RMI kan gebruiken met JRMP en IIOP. Twee verschillende protocollen. Leuke van IIOP is dat het CORBA compatible is, nadeel is dat het wat meer low-level is.

Het mooie van RMI is dat je gewoon java objecten naar de 'overkant' kan sturen die je vervolgens weer lokaal kunt gebruiken. Dat missen de andere twee alternatieven.

JRMP heeft leuke features als remote garbage collection en nog wat zaken.

Ehh, dat hebben ze allemaal wel hoor, anders zou je nogal snel door je geheugen heen zijn aangezien java gebouwd is om met een GC te werken. k snap deze opmerking dus niet helemaal.

De 1.3 JDK heeft op performance gebied heel wat verbeteringen gebracht.

Tja, dat zou je denken, maar ik kwam ook ergens een pagina tegen (heb de link even niet bij de hand) waar ze RMI bij de verschillende java VM's hadden getest, maar daaruit bleek eigenlijk dat er geen noemenswaardige snelheidsverschillen zaten tussen de verschillende versies. Dr valt op RMI implementatie niveau dus kennelijk niet al te veel meer te winnen.

[Soultaker]

Op woensdag 10 april 2002 22:29 schreef hondass50 het volgende:
Dr valt op RMI implementatie niveau dus kennelijk niet al te veel meer te winnen.

Zolang je een TCP-connectie (HTTP in het geval van Java RMI) gebruikt om gegevens heen en weer te sturen, zal dat je bottleneck blijven. Het marshallen van data valt daarbij over het algemeen in het niet, hoewel dat in Java redelijk complex is aangezien ook objecten by value doorgegeven kunnen worden. Alleen als je lokaal gebruik maakt van RMI zal het optimaliseren van andere onderdelen dan transmissie een significant verschil kunnen maken.

[Verwijderd]

Op woensdag 10 april 2002 23:25 schreef Soultaker het volgende:

[..]

Zolang je een TCP-connectie (HTTP in het geval van Java RMI) gebruikt om gegevens heen en weer te sturen, zal dat je bottleneck blijven.

HTTP wordt bij RMI alleen maar gebruikt als je FireWalls moet traversen. Er is niet zoveel verschil in het aantal bytes voor het verzenden via JRMP of IIOP, alleen wordt marshalling via CORBA sneller gedaan, omdat er niet hele objecten doorlopen hoeven te worden via introspectie.

[.oisyn]

Soultaker: HTTP wordt alleen gebruikt om de klassen en stubs te downloaden (en dat hoeft nog niet eens), maar het RMI protocol zelf is geen HTTP

.edit: ik moet sneller tiepen

[Exirion]

Het hangt er helemaal vanaf wat voor algoritmen je wilt uitvoeren. Ik heb wel eens parallel programming met C/MPI en Java RMI gedaan, en moest allerlei algoritmen tunen op performance. Voor sommige dingen is RMI heel elegant en efficient, maar vaak is C/MPI sneller. Alleen al doordat je C ipv Java gebruikt.

[Soultaker]

Sorry voor mijn domheid Is alweer lang geleden dat ik naar Java RMI keek.

[.oisyn]

domheid is niet hetzelfde als onwetendheid, dus dom zou ik je niet willen noemen (tenzij je jezelf dom vind, wie ben ik dan om daar niet mee in te stemmen )

[Verwijderd]

Op woensdag 10 april 2002 23:32 schreef PalmPal het volgende:

omdat er niet hele objecten doorlopen hoeven te worden via introspectie.

Als je die 'RMI optimizen' pagina bekijkt zul je zien dat je introspectie kunt voorkomen door zelf twee methoden te implementeren waarin je het serializen zelf doet.
Al met al staan er op die pagina behoorlijk wat van dit soort tips om performance behoorlijk omhoog te krijgen.

Exirion: De performance van de gehele applicatie zal eigenlijk voor >90% bepaald worden door de snelheid waarmee ik data kan versturen/ontvangen. Als Java+RMI beter presteerd dan Cpp+CORBA ben ik eigenlijk al tevreden. Temeer omdat in mijn situatie RMI (en dan met name Jini+JavaSpaces) beter geschikt zijn dan CORBA of een eigen socket oplossing.

[MisterData]

Er staat op www.javaworld.com een leuk artikel over 'Tweaking RMI for performance'. Daarin wordt beschreven hoe je RMI sneller zou kunnen maken (ik heb het gelezen, en alleen de serialization maakten ze al 4x zo snel). Lees dat eens, dan zul je zien dat er nog heel veel rek in de technologie achter RMI zit

edit:

[dombomodus sufheid="100%"]

hmm ik zie net dat dat de link is waarnaar de topicstarter verwijst

[/dombomodus]

[Verwijderd]

Okay, die RMI performance valt zo op het eerste gezicht allemaal heel erg mee! Eerst heb ik gekeken wat de performance van RMI tov een directe socket verbinding is (in java). In beide gevallen stuur ik evenveel bytes als data (hoewel RMI er intern dus nog wel wat bytes bij zal plakken). Uit die test bleek dat RMI wel iets trager is als de socket oplossing, maar het scheelt niet veel, k schat hooguit 10%.
Vervolgens heb ik de prestaties van een Java socket vergeleken met een C++ socket. In eerste instantie leek java op dit punt 50% langzamer! Dit bleek echter te komen doordat ik client en server op 1 machine draaide. (zo teste ik uiteraard ook mn C++ server+client). Toen ik in beide gevallen de client op een andere machine draaide als de server bleek de performance praktisch gelijk te zijn!!

Wat wel opvallend was en wat die 50% waarschijnlijk verklaart is dat mn C++ apps hooguit 20% en java 100% processortijd gebruikte.
Hoewel het slechts zeer beperkte tests zijn (ik heb nu bijvoorbeeld alleen bandwidth/throughput getest en niet delay, wat uiteraard ook erg belangrijk is, verder ook slechts 1 formaat pakketjes gebruikt van 30 bytes, alleen met jdk1.3 getest,geen directe vergelijking CORBA en RMI,etc,etc,etc).

Maar goed, mijn voorlopige conclusie is dus dat RMI/java sockets zeker niet zo slecht presteren als vaak wordt beweert. Er zijn dus situaties waarbij de performance praktisch gelijk ligt aan soortgelijke C++ applicaties, hoewel het nog niet duidelijk is voor welke en hoe veel situaties dit geldt.

Voor mij in ieder geval genoeg redenen om hier ooit nog eens wat beter naar te kijken en te onderzoeken of de performance ook zo goed is in het specifieke geval waarvoor ik RMI wil gaan gebruiken.