>Actually a lot of my concerns about RMI costs and such are coming from a
>recent interview I had which made me think of some things. Some I have
>rethought and have come to the conclusion they were not exactly
>correct. But
>then EJB is so new to both me (I've only been using the technology a few
>months and just moved to the 1.1 spec) and the place I interviewed
>at that I
>had to do some tests to see if the theorys were true or false. :) The cost
>in network traffic using RMI is not going to go away, the question becomes
>is that cost higher than we can affford or is the scalability important
>enough to warrant that higher cost. Personally I don't think that the cost
>is any worse than using JSP's or servlets. But I have not actually done any
>timing or performance tests. The advantage in my mind at least is the
>database pooling Which is also why I am such a fan of Stateless session
>beans. Pooling is much easier and less costly with them than with stateful.
Well, let me tell you the "little" bit that I do know. Just recently I
learned that two things will speed up EJB greatly. First, use statless ejb
sessions. I assume this means store the session stuff on the
JavaBean/HttpSession side of things, but this apparently cuts down in the
network traffic. Exactly how I am unclear of.
The second thing is to use EJB instance caching. This feature is built in to
app servers I believe..but it is not a J2EE requirement, so if your app
server doesn't do this, you would have to do this yourself. I think this may
not be a trivial task though, because in essence your writing your own EJB
container, or something similar. None the less, I believe the two tie in. By
using stateless ejb, and cached instances, you'll speed up the logic tier by
a lot. Again..I do not know for sure..but alot of people are confirming this
is the way to do it, and it will speed things up.
>Anyway I babble. Yes, everything you say is correct. Some of us just try to
>get every ounce of power possible from what we have. :) Sometimes
>that tends
>to make us worry worts. Jens probably has some figures on the costs and
>such, he has done much testing lately with these things.
You and me both. I am an optimizing freak! I am rewriting some things to
take advantage of using single-instance classes and local variables to
hopefully improve performance.
I anyone is in the know..what is the course of action if you use statless
ejb session beans? Do you store the sessional info on the HttpSession
web-server side? The reason I ask is I need to know what hardware to use,
how much memory, etc. We have a dual 500PIII as our front-end web server
(IBM NetFinity 4000R) with 512MB RAM and dual 9GB SCSI III drives, and I am
hoping this will be enough memory and power for some time to come. We only
have about 50 or so people a day on our site, but in about 2 years it could
exceed 1000 users a day. From what I have heard, this is SMALL potatoes
compred to a high-traffic site with several 1000 every minute hitting the
site. But, I would definitely like to keep in mind the ability to scale to
this level of performance anyways, just so I know how to do it. So, is
stateless/cacheable EJBs with JavaBean/HttpSession storage the way to go to
get maximum performance?
Thanks again.
