On Fri, Dec 11, 2009 at 11:13 PM, Aristedes Maniatis <ar..aniatis.org> wrote:
> On 12/12/09 12:45 PM, Michael Gentry wrote:
>>
>> Here is the result of our initial tests:
>>
>> http://spreadsheets.google.com/pub?key=tNytbSdt5wYIRTmTl4L-cCA&output=html
>
>
> * Are we to assume that all numbers are milliseconds?
Yes, all are in milliseconds.
> * How are you timing? From when the first thread starts until the last one
> completes? What do your results look like with one thread? Are you seeing
> some locking/concurrency issue?
I created a brand new DC in each thread, got the system time, ran the
query (and possibly committed a change), then got the system time
again to compute the difference. So the numbers are the time it takes
the thread to complete, for the most part (I kick them off at the same
time -- at least as closely as I can). My guess is it is
locking/concurrency, but I didn't have time to delve into it any
deeper (was the end of the day). When I ran RetrieveIndividual20 with
5 threads instead of 20 the results were MUCH closer to the Hibernate
values (sometimes better). (Keep in mind both ORMs had a limit of 5
open DB channels.)
> * There is so much variance between runs that something is odd here. What
> are you doing between runs to clear the cache? How are you dealing with
> variability at the database? Is the database running on another server which
> is unloaded and isn't itself interfering with the results?
I ran them several times and each time gave similar numbers. The ones
in the spreadsheet are just from the last run I did, but they were all
similar from run-to-run. The DB was on a different server, which is
also another reason I did several runs. I expect a few variances, but
the general pattern was the same. I don't have the QueryLogger
results here, but the DB times were significantly faster, so it really
was on the local Java side.
> * The huge variability makes me think that memory pressures might be
> important. Are you seeing the JVM garbage collect during the middle of some
> runs? Can you run jstat and see if that is interfering.
Didn't have time to get into GC. The machine I was on had about 5 GB
of RAM free and I had allocated plenty to the JVM. Also, fetching and
updating 20 records in the DB shouldn't be that memory intensive.
> * Are you able to pick the worst case (update) and time the various parts:
> create context, database UPDATE, commit finished... In your tests are you
> timing creating the context or is that outside the timing loop?
I was creating the DC outside of the timing. For
RetrieveIndividual20, the QueryLogger was showing DB times around 3ms.
I don't remember the others.
> * can you compare the SQL generated by the two ORMs and see if there is any
> difference at the database level
I might can do that on Monday, but given that the QueryLogger was
showing pretty quick responses from the DB, I don't think this would
matter much.
> Just a few thoughts....
Thanks!
mrg
This archive was generated by hypermail 2.0.0 : Fri Dec 11 2009 - 23:55:47 EST