Ritesh,
>From a design perspective I like your approach of traversing object
graphs to
obtain the required information, I do this wherever possible. As a EB
provider its always desirable to focus purely on your business problem
rather than thinking about server/container provider implementations and
adjusting your design to suit them. Hence, before you adjust your design
I'd
try squeezing as much as possible out of your deployment environment:
- If you aren't using Jeremie give it a go, its a lot faster for beans
communicating within the same jvm.
- Review jvm and jit options, some jits have options allowing
optimisation
for 'server' applications.
- Hardware, more memory/faster processors can often be cheaper than
redesigning a system.
If this isn't enough and you must design for performance you can try:
- Reducing the number of remote method invocations using 'Bulk
Accessors' (refer http://www.ejbnow.com/ejbtips/ejbtip_2.html)
- As you are obtaining information to populate read only drop down list
boxes rather than something the user modifies try obtaining the list
directly within a session bean via jdbc. I dislike this approach as it
requires the use of two different methods to access the same data (cmp
beans for updates and jdbc for listing). Either way you can't beat the
performance for generating large lists.
- Reduce the number of database updates by implementing isModified
methods
as described in the Jonas documentation.
Although there are situations it cant be avoided I'd think very
carefully
before modifying your design for performance. Sometimes the complexity
introduced can cost when looking at the long term
maintenance/extendibility
of a system.
You definitely aren't alone with concerns about performance, the
greatest of
which being the latency in remote calls between beans. This is an issue
faced by all EJB server providers (in fact all distributed component
systems) and is not specific to Jonas. I haven't performed any
benchmarking
but from my own work with Jonas/Jeremie have found its performance good
and
suspect it would compare well against other vendors implementations,
particularly those that rely solely on rmi.
Calvin.
----- Original Message -----
From: "Ritesh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 2:50 AM
Subject: How to improve the performance
> Hi All ,
>
> I am developing project on Car Fleet management .
> In that i have Car's manufacturer, makes models .
>
> Here is my problem scenario .
> Manu. ->Makes -> Models .
>
> I am having CMP for these three .
>
> I have ejbFindAllManu in my cmp for manufacturer.
> which gives me the all manufacturer.
> Then in loop for each manufacturer i have to get all the makes .
> so i have one ejbFindByManu on cmp make.
> Which gives me the all the makes for that manu.
> now for each makes i need the models .
> so i have one more ejbFindByMake on cmp Model .
> which give me all models .
>
> I have to do the above lopping because in front hand i have to
show
> all this in drop down boxes.
> If user select any manu. then the makes / models i have to
populated
> on the screen .
>
>
> As of now i am having only 15 Manu. 25 Makes , 200 Models .
> For the above data .
> My bean is taking lot of time to get the all the data .
>
> But If directly query to database the resule comes much fasters .
>
> Is this the Entity Beans probelm or JOnAS .
>
> Or somewhere i am going wrong ? .
>
> How can i improve the performance of my session bean .
>
> For this session bean my client is JSP which is conifgured on
> apache+gnugsp
>
> What are the factors i have to look at for getting good
performance
> from JOnAS.
> (any setting for jdbc / any time out / any properties)
>
>
> My JOnAS version is jonas-2.1.2 .
> Machine CONFIG :: Celeron 600 MHZ.
> 256 MB RAM .
> Databse Oracle 8i
> Platform Linux .
>
>
>
> Regards
> Ritesh.
>
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
