The other morning I was listening to Episode 17 the RIA Weekly Podcast. The RIA Weekly Podcast is always an excellent show that produces some of the most interesting content on the topic of Rich Internet Applications. This episode in particular caught my attention during the discussion on Enterprise scale applications. The guest for this episode was Richard Monson-Haefel of Curl, Inc. If you haven’t heard of Curl; it is a programming language and RIA development environment that is focused on the Enterprise.
Now I don’t want to get into some detailed comparison of SAP’s development tools to Curl’s but Richard brought up a particular topic that resonated with me. He was discussing how Enterprise RIA applications need to be able to handle very large datasets – his example was 100,000 rows – with very good performance. Looking back on my own experience as an SAP customer for 10 years, I can remember writing more than a few reports that had to chunk through 100,000+ records – usually destined to be ran by accountants. Although there are tools specifically designed to help process very large data sets in real time (for example BIA or Polestar), it is still nice to see just how far you can push the UI framework itself.
So without really wanting to draw comparisons to other tools, I simply wanted to see just how far I could push Web Dynpro ABAP and what kind of performance numbers I could get from it. Interestingly enough, just the other day Todor Petrov of IBSolution GmbH posted a Web Dynpro Java Context – Speed test. I had started building the examples for this blog a day before this blog was posted, so the similarities are pure coincidence – although I do wonder if perhaps we both listened to the RIA weekly podcast. 🙂
So I set out to test a large number of records in the Web Dynpro ABAP table UI element. I wanted to be able to test how long it took to load the records, scroll through the table and sort the table. I used the performance monitor built into Web Dynpro ABAP (activated by pressing CTRL-ALT-SHIFT-P). The response times are then broken down by roundtrip, server and client rendering.
I recorded videos of all my experiments which are posted below – but not to keep anyone in suspense let’s just say that WDA didn’t even break a sweat with 100,000 rows so I needed to push things harder and decided to add an option to test with 1,000,000 rows.
After you have watched the video, you will see that even 1,000,000 rows resulted in a really nice user experience – sorting in around 3 seconds. However the only drawback to this approach is that it does result in a large user session state – since the data is sorted in memory. The second option I decided to try out was using an ABAP Shared Memory object. ABAP has a very nice technique for table sharing and copy on change that makes it easy to access and use
shared memory objects without expanding your session memory footprint.
Now the only drawback to this approach was that once you sort the table, it still has to be copied into the session memory of the user. My final experiment was to try and use Context Paging. This Web Dynpro technique allows you to send small chunks of data to the Table UI element and have a server event triggered when more data is needed. This way I can go back to the database and read only small sections of data – yet the user can still sort and navigate through the entire dataSet. The response time was a bit longer for sorts since this option relies on SQL ORDER BY commands, but keeps the response time at quite usable levels while maintaining a tiny session memory footprint.