Hi ben, This morning I get all code from CVS and do my tests.
> A good improvement, but the
> similarity of the original execution times between Dianne and Marissa
> has me confused as to why your results reported a major difference in
> execution time between them.
Well, this occur because Marissa in my other test had access to all
contacts, and dianne only have access to 4 or 5 contacts (I change
that in code, sorry if I don't sayd that);
> As an aside, I wouldn't generally be encouraging people to return 10,000
> elements inside a Collection and then expect the ACL package to filter
> out all but 4 or 5 items. That sort of thing is an abuse of an RDBMS
> platform's inbuilt capabilities! :-) Still, we should aim to optimise
> the Java code as greatly as possible, so I am happy to explore this
> benchmarking and squeeze better performance out of it.
I agree with you :), but my test only have the purpose to see
scalability and optimize any code for extreme situation.
And now, my tests that I had done this morning:
1º I change DataSourcePopulator to populate permissions on all
contacts to user scott.
template.execute("INSERT INTO acl_permission VALUES (null, "
+ i + ", 'scott',"+permission+");");
2º I run tests and create a table with execution times ( see TemposAcegi.pdf )
Note: To use cache I change
applicationContext-common-authorization.xml with following:
<bean id="aclCacheManager"
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"/>
<bean id="aclCacheBackend"
class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager">
<ref local="aclCacheManager"/>
</property>
<property name="cacheName">
<value>aclCache</value>
</property>
<property name="timeToIdle">
<value>180</value>
</property>
<property name="timeToLive">
<value>180</value>
</property>
<property name="maxElementsInMemory">
<value>20000</value>
</property>
</bean>
<bean id="aclCache"
class="net.sf.acegisecurity.acl.basic.cache.EhCacheBasedAclEntryCache">
<property name="cache"><ref local="aclCacheBackend"/></property>
</bean>
<bean id="basicAclProvider"
class="net.sf.acegisecurity.acl.basic.BasicAclProvider">
<property name="basicAclDao"><ref local="basicAclExtendedDao"/></property>
<property name="basicAclEntryCache"><ref local="aclCache"/></property>
</bean>
I hope my tests could help code optimization.
Thanks,
Paulo
On 5/18/05, Ben Alex <[EMAIL PROTECTED]> wrote:
> Paulo Neves wrote:
>
> >My suggestion is, if we optimize time to remove domain objects we
> >optimize a lot all process.
> >
> >
> >
> Hi Paulo
>
> To make it easier to discuss and reproduce scalability related issues
> with the ACL packages, I've modified the Contacts sample to
> automatically create 1,000 extra Contacts and associated ACL records at
> startup. The DataSourcePopulator also has a "createEntities" parameter
> which can be changed to a larger number. This is now checked into CVS.
>
> I had DataSourcePopulator create 10,000 entities, and then I did the
> following:
>
> maven multiwar:multiwar
> deploy acegi-security-sample-contacts-filter.war to Tomcat 5.5
> visit the Contacts home page, then login as Marissa to view her contacts
> maven -Dusername=marissa -Dpassword=koala -DnrOfCalls=3 run
> maven -Dusername=dianne -Dpassword=emu -DnrOfCalls=3 run
>
> Then I repeated the above, but using your change to CollectionFilterer
> (of course I had to jar:install from /core firstly). Only HttpInvoker
> was used (this is now the default for Contacts). Initially it took
> 12,000 ms for Dianne and 12,047 for Marissa. With your changes it took
> 10,610 for Dianne and 10,687 for Marissa. A good improvement, but the
> similarity of the original execution times between Dianne and Marissa
> has me confused as to why your results reported a major difference in
> execution time between them.
>
> Would you please see if you can reproduce my results and perhaps
> re-check the original time difference between Dianne and Marissa.
>
> As an aside, I wouldn't generally be encouraging people to return 10,000
> elements inside a Collection and then expect the ACL package to filter
> out all but 4 or 5 items. That sort of thing is an abuse of an RDBMS
> platform's inbuilt capabilities! :-) Still, we should aim to optimise
> the Java code as greatly as possible, so I am happy to explore this
> benchmarking and squeee better performance out of it.
>
> Cheers
> Ben
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Home: http://acegisecurity.sourceforge.net
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>
TemposAcegi.pdf
Description: Adobe PDF document
