Here you can download JMeter stress test scripts:
1. ADF screen with regular SQL View Object - AMTestDefault.jmx
2. ADF screen with programmatic Coherence enabled View Object - AMTestCoherence.jmx
Scripts are configured to run 50 parallel threads, 1850 requests in total. Recorded script actions - use Next, Last, First and Previous buttons - navigate through rowset. Scroll down/up and select rows in af:table component:
I executed 30 runs for each of the screens - default SQL VO and Coherence cache based VO. Average request execution result for both screens: 1.34 seconds for Coherence cache VO and 1.62 seconds for SQL VO. This is logical result, because data is cached with Coherence and retrieved directly from the cache for each of the 50 users. While with SQL based VO, data is retrieved from DB each time new user (50 in total) opens a new session:
This shows - to retrieve data from Coherence cache is faster comparing to retrieving the same data from DB with SQL. Sample application is fairly basic, but the same tendency will be reflected in production enterprise systems. Of course we can't use Coherence for every use case, but for such use cases where fast data access is required - Coherence will be great help.
Below I show you samples from the stress test.
Coherence cache based VO:
SQL based VO:
Lessons learned: runtime performance is much faster when using programmatic VO as a wrapper to access data from Coherence cache, comparing to POJO bean (Data Access Optimization in ADF with Oracle Coherence) acting as a wrapper to access Coherence cache. This seems because ADF BC Data Control runtime performance is faster comparing to POJO Data Control performance - this is on my list to verify with another JMeter stress test.