There are really exciting news with ADF 11g PS3, I did some practical test experiments and can see that ADF runtime performance with the new release is about 2-3 times faster comparing to previous ADF 11g PS2 release. Performance tests were done on production project, I replicated the same tests on sample application based on standard example HR schema from Oracle XE database. Both tests for PS2 and PS3 were done on the same machine, the same ADF application. I will not only describe performance improvements in PS3, but will go a bit deeper and describe performance friendly patterns for CRUD type operations. I will be focusing on editable/read-only ADF tables comparison for CRUD type operations - CRUD Operations in Oracle ADF 11g Table Without Auto PPR.
Download typical Master-Detail ADF sample application - ChoiceListPerformance2.zip. All experiments in this blog post will be done based on that sample.
This application contains Master data page for Departments - tests will performed with DepartmentId = 50:
Detail data - editable Employees table at first run is opened in 3.97 seconds (PS2):
During second run, same table is opened in 2.13 seconds (PS2):
Logically, second run is faster, because required components static data (Java Script, images, etc.) was already loaded during the first run.
Will repeat the same actions with PS3. At first run, detail table is loaded in 2.97 seconds (PS3). Which is by 1 second faster comparing to previous PS2 release - good improvement:
During second run, same screen opens in 1.13 seconds (PS3). Again, exactly by 1 second faster, comparing to the same test on PS2 release:
Okej, it was editable table test. Let's try to achieve less than 1 second opening for the detail screen. Will try to enable clickToEdit mode for editable ADF table - change Editing Mode property:
The same detail screen on PS2 opens in 3.63 seconds (PS2) at first run, there is slight improvement, but not much:
During second run, it opens in 2.2 seconds (PS2) - even slower or almost the same as editable table:
It looks like there is no difference in terms of performance to use directly editable table or clickToEdit functionality.
Let's look how the same mode (clickToEdit) will perform on PS3. First run of detail screen gives 2.38 seconds (PS3). This is faster then editable PS3 and PS2, but still more than 1 second:
Finally, second run gives 1.08 seconds (PS3) - we are close to 1 second (clickToEdit helps us in PS3):
What if we consider different approach and will use read-only table, user will be allowed to edit records by invoking editable ADF Faces popup (description - CRUD Operations in Oracle ADF 11g Table Without Auto PPR). From my experience, this approach is quite popular and users prefer it especially for large and complex tables. We create read-only table for detail data:
Will enable row selection, this will help user to open popup through double-click on the row:
In order to enable popup opening by row double-click, add clientListener and serverListener to the table component:
clientListener will handle row double-click event:
serverListener will call backing bean method to raise popup:
JSF Fragment component contains Java Script for clientListener:
serverListener calls simple backing bean method and opens popup component:
During first run, it gives now 2.83 seconds (PS2) for read-only table, obviously faster comparing to editable or clickToEdit approaches:
Yes, during second run we have 781 mili-seconds (PS2), finally less than a second ! Here we go:
User can double-click on the record - editable popup is opened in 1.13 seconds (PS2):
On the second run, editable popup is opened faster in 813 mili-seconds (PS2):
Pop-up is closed in 672 mili-seconds (PS2):
Now we will test read-only table opening performance on PS3. During first run, it opens record fast - just 1.05 seconds (PS3):
Second run for read-only table is completed super fast - in 329 mili-seconds (PS3):
Editable pop-up opening is done in 703 mili-seconds (PS3):
Pop-up is closed in 234 mili-seconds (PS3):
I'm really happy to see such great ADF 11g PS3 runtime performance improvements !
Download typical Master-Detail ADF sample application - ChoiceListPerformance2.zip. All experiments in this blog post will be done based on that sample.
This application contains Master data page for Departments - tests will performed with DepartmentId = 50:
Detail data - editable Employees table at first run is opened in 3.97 seconds (PS2):
During second run, same table is opened in 2.13 seconds (PS2):
Logically, second run is faster, because required components static data (Java Script, images, etc.) was already loaded during the first run.
Will repeat the same actions with PS3. At first run, detail table is loaded in 2.97 seconds (PS3). Which is by 1 second faster comparing to previous PS2 release - good improvement:
During second run, same screen opens in 1.13 seconds (PS3). Again, exactly by 1 second faster, comparing to the same test on PS2 release:
Okej, it was editable table test. Let's try to achieve less than 1 second opening for the detail screen. Will try to enable clickToEdit mode for editable ADF table - change Editing Mode property:
The same detail screen on PS2 opens in 3.63 seconds (PS2) at first run, there is slight improvement, but not much:
During second run, it opens in 2.2 seconds (PS2) - even slower or almost the same as editable table:
It looks like there is no difference in terms of performance to use directly editable table or clickToEdit functionality.
Let's look how the same mode (clickToEdit) will perform on PS3. First run of detail screen gives 2.38 seconds (PS3). This is faster then editable PS3 and PS2, but still more than 1 second:
Finally, second run gives 1.08 seconds (PS3) - we are close to 1 second (clickToEdit helps us in PS3):
What if we consider different approach and will use read-only table, user will be allowed to edit records by invoking editable ADF Faces popup (description - CRUD Operations in Oracle ADF 11g Table Without Auto PPR). From my experience, this approach is quite popular and users prefer it especially for large and complex tables. We create read-only table for detail data:
Will enable row selection, this will help user to open popup through double-click on the row:
In order to enable popup opening by row double-click, add clientListener and serverListener to the table component:
clientListener will handle row double-click event:
serverListener will call backing bean method to raise popup:
JSF Fragment component contains Java Script for clientListener:
serverListener calls simple backing bean method and opens popup component:
During first run, it gives now 2.83 seconds (PS2) for read-only table, obviously faster comparing to editable or clickToEdit approaches:
Yes, during second run we have 781 mili-seconds (PS2), finally less than a second ! Here we go:
User can double-click on the record - editable popup is opened in 1.13 seconds (PS2):
On the second run, editable popup is opened faster in 813 mili-seconds (PS2):
Pop-up is closed in 672 mili-seconds (PS2):
Now we will test read-only table opening performance on PS3. During first run, it opens record fast - just 1.05 seconds (PS3):
Second run for read-only table is completed super fast - in 329 mili-seconds (PS3):
Editable pop-up opening is done in 703 mili-seconds (PS3):
Pop-up is closed in 234 mili-seconds (PS3):
I'm really happy to see such great ADF 11g PS3 runtime performance improvements !
5 comments:
I see you have done these tests with Firefox. Have you tried it with IE?
I have done these tests with Firefox, mainly because of FireBug extension to get time statistics.
On IE, ADF 11g PS3 works even slightly faster comparing to Firefox.
But Safari is the fastest ! :)
Regards,
Andrejus
Thanks for the good statistics. Is there an performance advantage between the "old" shop-popup-method via ExtendedRenderKitService and the "new" show-method in oracle.adf.view.rich.component.rich.RichPopup? Have you already tested?
Best regards,
Martin
Hi Martin,
I didnt tested yet new show method for PopUp, will be interesting to see how it works.
Andrejus
Hi , I've implemented a declarative component that uses a row.attribute as a parameter in a table so it renders the dec. component for each row with diferent values . in this new realese of jdev for some reason , it has stopped working and now it just copies the first row components to the whole table. I was hopping someone might have a workaround or at least if you think it will be solved by remaking the dec component in the rs3 .
Post a Comment