Skip to Content

Web Dynpro Java Context – Speed test

Recently I had some discussions with a customer of ours that landed doubt on the fact that Web Dynpro context access is the fastest possible way to create and retrieve data within a Web Dynpro application. Since I didn’t found any benchmarks from SAP direct, I just decided to test the thing myself.

The application is relatively simple, including one non-visual and one visual controller with their contexts mapped. The component controller context looks like this:


We have a context node People that is mapped to a Structure and having the cardinality: 0..n. The other node is just a helper to hold the record count attribute, which is mapped to the input field in the view controller. The complete UI mask has the following look:


The button on top is mapped to an action that calls a method in the non-visual controller. The method itself implements the creation of the elements and the calculation the time intervals:

public void createRecords( int recordsNo )
//@@begin createRecords()
long startTime = System.currentTimeMillis();
int i=0;
for(i=recordsNo; –i>=0;){
IPeopleElement peopleElement = wdContext.nodePeople().createPeopleElement();
long endTime = System.currentTimeMillis();
this.msgManager.reportSuccess(“Elapsed time: “+(endTime-startTime)/1000+ ” s”);

Our application is ready to be tested. I’ve ran it for 4 different record counts a couple of times. You can see the results in the following table:

Created records

Estimated time


0 sec.


0 sec.


0 – 3 sec.


14 – 21 sec.

A screenshot from the last test also shows that the record creation for 1 million records could vary depending on the current load of the J2EE Server:


I guess after this small representation of what the Web Dynpro context is capable of, no one is in doubt that it is one of the fastest possible way to access data in a running Web Dynpro application.

On popular demand I also tested how long it would take to save the data to a java array from a java class that has the same properties. The results were impressive – 1 000 000 records within 3 to 4 seconds. Not bad, but we must not forget that this includes only writing to the array and the display is not taken into account and believe me displaying a java array in Web Dynpro still means that you have to save the data to the context. Another aspect is the typed API that the Web Dynpro context provides and is so easy to work with. Whereas with java classes, we would have to generate the get and set methods manually or at best automatically with NWDS integrated functionality.

You must be Logged on to comment or reply to a post.
    • Well i already have experience with the Portal database access and other backends (ABAP). The purpose of the blog was just to test the speed of the context access as the title suggests, but i can bet also that it the fastest also..if you manage to write 1 000 000 entries anywhere and read them back in 13 seconds, i would be more than glad to see it in action:)
      • Todor, you can’t compare a Web Dynpro context to persistent backends. And time “measuring” without load tests and SAPS declarations is not really comparable. Maybe you’re twice as fast on a different server. Maybe you totally crash your server when scaling up the users.
        Of course context access is fast. It’s like putting an object to a list. I really don’t get the point of this test and why you share it with the rest world.
        Cheers, Karsten
        • Hi Karsten,

          the reason why I shared it with the rest of the world is mentioned at the beginning of the blog. You are right about comparing persistent and temporary storage and that is why I added some additional info at the end of the blog, at which you might want to take a look. As for the load tests and SAPS declaration, I agree with you to the point where I should make clear that those are no official SAP results, just a test, which was made on a server where only I was currently logged in. And since the other results are also made on the same machine the ration between them will be kept, no matter the SAPS, which your server has. To summarize just short, the point of the blog is to show how the amount of the entries in the context affects response times – as we see until 100 000 entries, there is no big difference.


          • Todor, is this your conclusion? That you could put 100.000 elements to a context without performance issues? Don’t you think it depends on how many users user your application concurrently? Don’t you think it also depends on how big your elements are and how many bytes they reserve? Your response times totally depend on your overall server load. How many memory is free on the heap, how often the vm has to run garbage collections, etc. When holding 100000 elements in a list for each user your vm might easily bid farewell with a nice OOM. Big difference.
          • Hi Karsten,

            i don’t see what you are trying to prove currently. As I said no one obliges you to follow the test results or to take them for granted. They are such according to the conditions under which I tested and the customer, for which this blog was intended is completely happy with it. So if you would like to provide a deeper insight on the Web Dynpro performance, then be my guest. I am looking forward to that blog.


          • Hi Todor,

            I think that what Karsten means is that your conclusions might be misleading. You came across some interesting numbers…OK. But that shows you just how fast you hardware can process that amount of information in memory. You are in fact not testing the technology behind Webdynpro – you are just getting results about the system performance while processing a java application in memory. After all, WD context is technically speaking a memory portion allocated for your application in a user’s session. The number’s you are getting represent the amount of time java takes to create object instances of class ZZZ and set their attributes to point to another variable in memory. All in all it is just another way to measure how fast a method can go on your hardware using a particular computing language.
            I don’t see a practical reason for such a test either other the exposed here. Perhaps you can share why the customer was interested with it in the first place. Perhaps the question was misconceived to begin with?

            Kind regards,

          • Hi Ivan,

            all that you have written is absolutely true. However testing two technologies on a one piece of hardware offers more or less comparable results. So the point of the blog, was to show the customer that the bottle neck in the performance is not the WD Context, but rather other API calls to the portal. I hope this makes more sense now.

            Thanks for the comment,

          • Karsten, why do you have a problem with Todor’s blog? He just showed how fast is WD context. I think is good to know that context is so fast and we can store in it so many records in relative short time. Todor doesn’t proclaim his results like scientific or exactly comparable.
            Yes, show us better and more professional approach – we will see if you come with something better.