Thanks for you answer.
> I think your test case has a few drawbacks and do not reflect a > production scenario.
Our clients are asking our datas every 3 sec through a web service. So this case'll occure a lot i think.
I tried to launch a first dummy call before the others. It reduce a little the response time but not to much.
If i send my requests in a for loop, each request takes 200 ms and if i do the same but in threads instead of the loop , it takes up to 3 seconds !
> This depends on the used ObjectCache implementation
I tried all the objectcache but the performance are almost the same.
> The object you try to materialize will be put to cache when it is fully > materialized (e.g. if you set autoRetrieve 'true' to reference > descriptors they will be load too). So if multiple concurrent threads > try to lookup the same object (and you use the default cache), they may > materialize the object several times because none of the threads has put > a fully materialized object to cache.
My first "dummy" call is in fact the same call to getCollectionByQuery. So normally all my object should already be in cache and the next queries sould take a lot less time, aren't they ?
Armin Waibel wrote:
Hi Cyril,
I think your test case has a few drawbacks and do not reflect a production scenario.
First time PBF was used OJB parse and create all metadata objects (OJB startup phase), this is time consuming and only occur one time in OJB runtime. So before you start the LoadThread classes you should do a dummy operation on OJB to force OJB startup.
>> If i launch the same series of threads a second time, the calls take 2
>> or 3 less time. Same if i put a second call to getCollectionByQuery in
>> my run method.
>>
>> So it seems that ojb has a cache for each thread and not a general cache.
This depends on the used ObjectCache implementation
http://db.apache.org/ojb/docu/guides/objectcache.html#Shipped+cache+implementations
The object you try to materialize will be put to cache when it is fully materialized (e.g. if you set autoRetrieve 'true' to reference descriptors they will be load too). So if multiple concurrent threads try to lookup the same object (and you use the default cache), they may materialize the object several times because none of the threads has put a fully materialized object to cache.
By the way, if you use OJB source distribution you can run a multi-threaded performance test against (hsql by default) with 'ant perf-test'
http://db.apache.org/ojb/docu/guides/performance.html#OJB+performance+in+multi-threaded+environments
regards, Armin
Cyril Ledru wrote:
Hi,
I there a problem with my mail ? Did i forget something ? I am not clear ?
Please, tell me, i really need this info.
Cyril Ledru wrote:
Hi all,
This is my problem : I have an application which launch several threads. In each thread, there is a call to getCollectionByQuery.
Here is the code of my thread class :
public class LoadThread extends Thread {
public void run() {
PBKey pbkey = new PBKey(...,...,...);
PersistenceBroker pb = null;
try {
pb =PersistenceBrokerFactory.createPersistenceBroker(pbkey);
Collection c = pb.getCollectionByQuery(new QueryByCriteria( Employee.class));
} finally {
if (null != pb) {
pb.close();
}
}
}
}
Then i launch this threads :
LoadThread[] ts = new LoadThread[10]; for (int i = 0; i < ts.length; i++) { ts[i] = new LoadThread(); }
for (int i = 0; i < ts.length; i++) { ts[i].start(); }
This is quite simple. The problem is the response time are abnormally high. Usually, only the first call is time consuming because ojb mount the objects in cache and the next calls should take a lot less time.
But here all the calls are time consuming.
If i launch the same series of threads a second time, the calls take 2 or 3 less time. Same if i put a second call to getCollectionByQuery in my run method.
So it seems that ojb has a cache for each thread and not a general cache.
Am i using ojb incorrectly or is ojb incapable of caching datas for all the threads ?
In the second case, is someone knows a way of caching for all the threads ?
Thanks in advance , Cyril.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
