Randy this is very interesting, please move to jboss-dev and add your comments to the entry in bugzilla. Don't worry we will get you there. There is too much commercial interest around jboss for it not to happen. The RMI point is small, it doesn't go through RMI but then there is serialization. This was part of the optimization with Tomcat. For the VM non Jitting the code, I am surprised... we need to seriously adress the performance soon. And start looking at it scientifically. jboss 2.0 is close to be a finished product from the container and basic plugins standpoint. Then we will need the complete user doco (the mail of yesterday was only complaining "where is the doco to do this and that") and the speed. jboss1.0 was cruising as fast as weblogic there is no reason even though jboss 2.0 is a more modular architecture that we wouldn't reach those speeds again. So don't worry, I hope it makes the cut for your production decision, but it will get there in time. kind regards marc > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Randy Chapman > Sent: Saturday, July 29, 2000 8:45 AM > To: [EMAIL PROTECTED] > Subject: [jBoss-User] jBoss somehow disabling JIT, and other > performanceconcerns... > > > > I've done some basic tests on the jBoss CVS snapshot of earlier this > work, specifically in regards to performance. I can't say that the > results are impressive, but I've noticed three things that I suspect > lead to 90% of the problem. I was wondering if anyone might have > suggestions for us ? > > Issue 1: Some simple testing indicates that neither IBM's 1.3 VM, nor > Sun's 1.3 VM (both cases, on both Linux and w2k), is capable of > JIT-compiling the code. IBM leaves a distinct marker in JIT-compiled > code -- backtraces of exceptions lose line numbers. I wrote a simple > program and tried it in and out of jBoss, and backtraced line numbers > disappeared in the standalone version, but not in the VM. Further, > performance did not degrade at all when I manually disabled the VM by > setting JAVA_COMP to NONE. This undoubtable accounts for a tremendous > amount of the performance lack I see. I remember reading something > about removing the SecurityManager code causing a major difference in > performance -- I wonder if this is related ? Unfortunately, the message > did not give details on how to do this. Anyone have suggestions before > I go digging through code ? > > Issue 2: Session bean to entity bean goes through RMI, instead of > direct. I've read that it is NOT supposed to work that way -- any ideas > what I might be doing wrong ? > > Issue 3: Transactions appear to be started when you call a > <Home>.create() on an object that has NotSupported, or even Supported, > in the deployment descriptor. TX_SUPPORTED is listed for the .create > call in the log. Any ideas how to remove this transaction ? > <container-transaction> > <method> > <ejb-name>ExpertPaymentAccount</ejb-name> > Do I need to do this for ExpertPaymentAccountHome as well ? > > Thanks! > --randy > > ps: I'm really trying to avoid spending the $1500 per machine on orion > server, but we need to deploy soon :-( I fear spending the money mostly > because I don't know how long they might stay around, or what kind of > support we might get, and I really want to see jBoss beat the pants off > them in at least bean performance pretty soon. Being based on Tomcat, I > fear there's no hope on jsp/servlet performance, but I plan on writing a > SOAP layer anyways.... > > > > > > -- > -------------------------------------------------------------- > To subscribe: [EMAIL PROTECTED] > To unsubscribe: [EMAIL PROTECTED] > Problems?: [EMAIL PROTECTED] > > -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED]
