Wasn�t aware of that, good news. Better news is that I even yet not have done any optimisation/profiling attempt at jboss.net simply because functionality�s first.
I guess that the figures will significantly improve after the rewrite of EJBProvider for injecting calls into the JBoss invocation stack directly. This is planned for JB4 final. Overall: loosely coupled communication always has a higher latency due to connection issues and due to more verbose protocol handling ... Thats why you should use it for the right parts of your architecture (certainly not for db-tier or technical backend stuff). Thats why you should do infrequent batch calls rather than frequent ping() accesses. Special: I guess there is still a whole lot of potential for tweaking the Axis engine. So do not despair, but rather profile your communication and help to bring jboss.net equals heads to .NET ;-) CGJ > -----Urspr�ngliche Nachricht----- > Von: Bill Burke [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 26. Juni 2003 00:43 > An: [EMAIL PROTECTED] > Betreff: RE: [JBoss-user] JBoss-Net performance issues > > > I recent study put JBoss.net ahead of other J2EE vendors in > performance. http://www.formsite.com/doculabs/atbench/index.html > > You're always going to get crappy performance. You're doing > XML parsing don't forget instead of putting the bytes right > on the stream. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Barlow, > > Dustin > > Sent: Wednesday, June 25, 2003 4:41 PM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-user] JBoss-Net performance issues > > > > > > I've been playing with the simple Hello jboss-net code > included in the > > samples directory. I did some performance testing and the > results are > > quite stunning. > > > > The test was simple. I used the included sample Axis test > client to > > call the hello(String name) method but instead of passing > it a short > > string, I decided to make things a little more interesting > and pass it > > a 75k and then a 275k string of XML read from a file. The > EJB hello > > method did nothing other then accept the data as a > parameter, and echo > > back the size of the data that was passed into the method. > I was very > > surprised at how long it took run. > > > > I then decided to side step Axis and invoke the EJB > directly passing > > it the 75k and 275k data chunks. The difference in performance was > > quite large. > > > > The stats below were gathered by running the hello(String > name) method > > 10 times in a row. One test using the Axis client, and one using a > > RMI client directly to the EJB. BTW, the test only included the > > "invoke" method in the > > loop, not the lookups of the Axis service or EJB. The > lookups and binding > > in both tests were only done once at the beginning. > > > > 10 interations | 75k | 275k > > ---------------|----------|-------- > > JBoss-NET: | 16 secs | 68 secs > > RMI->EJB: | 3 secs | 8 secs > > > > The overall duration of each test run would certainly vary > on faster > > iron, but the ratio between the two sets of test numbers > would likely > > be the same. I do realize that the remote method invocation > via Axis > > is going to be slower because of the extra layer and > marshalling that > > needs to be done, but > > I did not expect such a large difference. > > > > It also seems that the larger the data is that performance does not > > decline linearly, but seems to be more exponential in its lose > > compared to RMI->EJB. > > > > Is there anything that can be done to improve JBoss-Net > performance? > > Is this just systemic to Axis/SOAP? I did notice that the > performance > > gap between the two was smaller with less then 10k data > files. This > > tends to make me think that the performance degredation is > less due to > > the actual invocation of the method and more to do with the > > marshalling of data. > > > > Dustin > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: INetU > > Attention Web Developers & Consultants: Become An INetU Hosting > > Partner. Refer Dedicated Servers. We Manage Them. You Get > 10% Monthly > > Commission! INetU Dedicated Managed Hosting > > http://www.inetu.net/partner/index.php > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU > Hosting Partner. Refer Dedicated Servers. We Manage Them. You > Get 10% Monthly Commission! INetU Dedicated Managed Hosting > http://www.inetu.net/partner/index.php > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/j> boss-user > ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
