[jbosscache-dev] Restructuring o.j.c.l.JDBCCacheLoaderPerfTest, thoughts?

[Galder Zamarreno]

You're right actually, putting them into a single method would make profiling harder as it wouldn't be that obvious to see the benefits your changes could have in the put area, or get area...etc.

If we added that put loop at the beginning of get and remove methods, it'd distort the profiling results of that tests, wouldn't they?

I'm rolling back on my initial thoughts actually. We could still control the flow implementing the "public static Test suite()" method and leave the tests independent to make profiling easier which is their objective.

I'll change the remove on tear down to evict to still benefit from the original puts.

Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat

IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/

-----Original Message-----
From: Manik Surtani [mailto:manik at jboss.org] 
Sent: 06 December 2006 12:25
To: Galder Zamarreno
Cc: jbosscache-dev at lists.jboss.org
Subject: Re: [jbosscache-dev] Restructuring o.j.c.l.JDBCCacheLoaderPerfTest, thoughts?

On 6 Dec 2006, at 10:32, Galder Zamarreno wrote:

> Hi,
>
>
>
> Over the last few days I have been having a look at  
> o.j.c.l.JDBCCacheLoaderPerfTest and I have come to the conclusion  
> that it needs changing.


>
>
> Currently there're 3 tests, testPut(), testGet() and testRemove().  
> I tried running it and I realised that testPut() would do its job  
> but the other two would never find anything in the database.
>
>
>
> This could be controlled via setting drop table to false, but this  
> would still not work as cache.remove("/") is called on teardown().
>
>
>
> These three tests are quite linked to each other as you expect puts  
> to go first, then gets and lastly removes. When running unit tests,  
> you're not guaranteed order and taking in account the relationship  
> between the tests, I think the code inside these tests should be  
> joined into just one test.
>
>
>
> Of couse, you'd need to evict the cache in between puts/gets and  
> gets/removes so that you can actually exercise the code fully right  
> up to the cache loader.
>
>
>
> Any thoughts?

Yes, something moving to TestNG would help with someday - finer  
grained control over test setup and teardown structures as well as  
the relationships between tests.

Keep in mind though, the purpose of this test is not like other unit,  
stress or perf tests.  It does not exercise functionality nor look  
for bugs/leaks over time, nor measure any meaningful benchmarks.  It  
is simply an exercise to micro-bench individual operations so that,  
while tuning the cacheloader code, you can measure the effect of your  
enhancements.  So this really should be treated more as a tuning tool  
than anything else (and probably should be excluded from the cruise  
control test suite as it is meaningless when run in CC)

And treating it as such a tool, the put, get and remove test methods  
should be treated separately IMO.  Moving them into a single method  
may make profiling a bit hard.  I see your point about setting up the  
cache with proper data for get and remove tests though; perhaps  
include a put loop at the start of get and remove to init the cache  
first?

>
>
> Galder Zamarreño
>
> Sr. Software Maintenance Engineer
>
> JBoss, a division of Red Hat
>
>
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/ 
> promo/vendor/
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev