Great. Thanks for your help! Oleg
-----Original Message----- From: Andy Malakov [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 4:43 PM To: OJB Users List Subject: Re: Slow query via PersistenceBroker Oleg, Overhead is per-JVM. Warm up OJB before starting multithreaded performance test (unless you want to test that concurrent initialization works :-). I would measure average time instead of single query timing - remember that System.currentTimeMillis() may not be precise (e.g. on Windows platform). Good Luck, Andy ----- Original Message ----- From: "Oleg Lebedev" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Friday, February 13, 2004 6:29 PM Subject: RE: Slow query via PersistenceBroker Andy, I ran the query 3 times in a sequence and performance did improve, which is good news. I am actually executing this query in 5 concurrent threads. Each thread performance conforms to the same pattern: first query run takes about 2000 ms, the second run ~ 60ms and the third run is ~ 15ms. I hope that this overhead is per JVM and not per query! Are there any optimizations that I can do to improve PB performance? As far as I understand PB provides the best performance compared to ODMG and JDO, is that right? Thanks. Oleg -----Original Message----- From: Andy Malakov [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 4:17 PM To: OJB Users List Subject: Re: Slow query via PersistenceBroker Hello Oleg, OJB needs some time perform one-time initialization (load all library classes, initialize metadata registry, etc). Execute your test method several times to warm up OJB and JVM before measuring it performance. ----- Original Message ----- From: "Oleg Lebedev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 13, 2004 6:04 PM Subject: Slow query via PersistenceBroker Hi all. I just barely started using OJB and have a problem with performance. I was following "The Persistence Broker API" tutorial and tried to retrieve a single record from the database table which contains about 150 rows. It takes 1500ms to execute this query and get the result back! I am using SQL Server and the query takes a couple of milliseconds when executed directly from the database. In the code below it takes 800ms to allocate the broker and 600ms to execute the query. Why is it so slow and what's the best way to avoid such delays? Thanks. Oleg CODE: public static Objective findObjectiveById(int id) { System.out.println("findObjectiveById(" + id + ")"); long start = System.currentTimeMillis(); Objective result = null; PersistenceBroker broker = null; try { broker = PersistenceBrokerFactory.defaultPersistenceBroker(); System.out.println("Allocated broker in " + (System.currentTimeMillis() - start) + "ms."); start = System.currentTimeMillis(); // For small datasets use Collection as shown below. Criteria crit = new Criteria(); crit.addEqualTo("objid", new Integer(id)); QueryByCriteria query = QueryFactory.newQuery(Objective.class, crit); System.out.println("Created query in " + (System.currentTimeMillis() - start) + "ms."); start = System.currentTimeMillis(); try { // ask the broker to retrieve a Collection Collection results = broker.getCollectionByQuery(query); System.out.println("Executed query in " + (System.currentTimeMillis() - start) + "ms."); start = System.currentTimeMillis(); // print the results Iterator iter = results.iterator(); if (iter.hasNext()) { result = (Objective)iter.next(); } System.out.println("Obtained result in " + (System.currentTimeMillis() - start) + "ms."); start = System.currentTimeMillis(); } catch (Throwable t) { t.printStackTrace(); } } catch (Throwable t) { t.printStackTrace(); } finally { if (broker != null) broker.close(); System.out.println("DONE executing findObjectiveById."); } return result; } ************************************* This e-mail may contain privileged or confidential material intended for the named recipient only. If you are not the named recipient, delete this message and all attachments. Unauthorized reviewing, copying, printing, disclosing, or otherwise using information in this e-mail is prohibited. We reserve the right to monitor e-mail sent through our network. ************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ************************************* This e-mail may contain privileged or confidential material intended for the named recipient only. If you are not the named recipient, delete this message and all attachments. Unauthorized reviewing, copying, printing, disclosing, or otherwise using information in this e-mail is prohibited. We reserve the right to monitor e-mail sent through our network. ************************************* --------------------------------------------------------------------- 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] ************************************* This e-mail may contain privileged or confidential material intended for the named recipient only. If you are not the named recipient, delete this message and all attachments. Unauthorized reviewing, copying, printing, disclosing, or otherwise using information in this e-mail is prohibited. We reserve the right to monitor e-mail sent through our network. ************************************* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
