Portal Server performance on DropDown UI (by index) element.

[Former Member]

Hi All,

I've a requirement is to populate values (over 1000 entries) from DB (RDBMS) into WD DropDownByIndex UI element. And we may have around 5 DDBI elements in a single form..! So just want to understand the 'load and impact' on the portal server on production due to these requirements (we didn't had these cust rqmnts during portal sizing). I've tested by looping with 1000 value and didn't see much of difference, but it cud effect on production during multi-user logons.

I want to know any technical comments and suggestions to understand better before i suggest an alternative way!!!

Thanks to all in advance,

MS

[Former Member · Accepted solution]

hi

we also had a similar application that was developed which loads 30,000 data , with about 5 ItemListBoxes ,

we had to use ItemLIstBox sothat mutliselection is allowed here when compared to dropdownbyindex ,

and we had a filtering approaching approach taken from R/3 side , sothat there would be no duplicated data

that would be populated and we have been populating data in the ItemListBox , and we are populating data

in the first dropdown with some data and later on click on one of the item from the one drop down other

dropdown gets populates and rest follows that same .

We had tested the data with populated 2500 record inthe itemlistbox on the page load inthe wdinit() method

there was no performance issue , the page gets loaded with no time .

If possible you also follow the same approach .

Thanks

[Former Member · Accepted solution]

Hi Murali,

Your statistics make me little comfortable, but you have not shared the noof users on prod system, can you?

And in our case i don't have the dependencies between dropdowns, they are independent. And let me first try ItemListBoxes as you said and come back with comments.

Anyways thanks for the inputs.

Thanks,

MS

[Former Member · Accepted solution]

Hi Munna,

Though you can load all the 1000 entries in one stretch I think it will be better if you can load say some 100 or 200 entries first and as the user scrolls down have another value in the DD say 'more' which will fetch next set of records. In this way you can avoid loading all the entries in the init method itself. This is how it even works in R3 tables if there are huge set of records returned.

Regards,

Ponraj M

[Former Member]

hi

with the application loading 2500 records in the itemlistbox in case of our application

we did face any problem any problem in the using it , i had done the developement in the DEV

but we had given the access to the Test Users who were accessing , there was no problem ,

and with respect to 1000 it should not be any problem ,

[Former Member]

Hi,

I'd try use another UI Element to perform this operation, like OVS or EVS. This using something like one thousand or less items. For something like thirty thousands, I'd do a round-trip and query the back-end, to get only relevant data.

Thus a Drop Down can be populated with a lot of entries, it consumes a lot of of client-side memory. If you are using a browser like Firefox, this should be a lot less "visible" then IE.

One more thing to be careful, this will probably increase a lot the "size" of your web-page, since this is not server-side. You will have a huge HTML to load due to this drop-down, when using over local network this should not be visible, but it will be visible when the access comes from external.

Regards,

Daniel

[Former Member]

Hi,

As per my knowledge it may effect if you are loading all these dropdowns in the init() and if no of concurrent users are huge.

is it a external-customer portal? If yes then there is a chace of more no of concurrent users in production.

If suggest fist to do the performace load test then based on that results you can think about alternatives.

If you embed all the Dropdowns in the single view then the screen loads only once all the data populated in all the dropdowns.

So screen loading takes some time.

The alternative is: Then split the portal screen into different iviews.

In the WebDynpro design the views as below:

Application1>Window1->View1 (Which contails DropDown 1, DropDown2)

Application2>Window2->View2 (Which contails DropDown 3, DropDown4)

Application3>Window3->View3 (Which contails DropDown 5)

So now create three ivews in the portal and integrate three ivews in the same portal. So these ivews loads independently.

You can use EPCF (Raise Event, Subscribe Event) to trigget the actions from one iView to another within this page if requried.

Regards,

Charan

[Former Member]

Hi Charan,

Thanks for the reply.

Well i've no other choice, so i'm calling this method (getXXX()) from init() and its an internal portal only.

Our client is already in plans for Loading testing for ERP applications, but it might take some time.

Your alternative may not be acceptable to client as the form is divided into multiple views!!

My alternative solution would be 'providing an action link next to input-field(replacing DD UI) which opens up a popup window with all the data populated in a table to select a value and with a filter if required'. This will avoid going for multi-screen and ofcourse calling DB cons in init().

But the client is (may) not interested in many clicks for a single value to select, so the reason i'm really looking for a strong technical challenge in having DDBI with said number.

Thanks,

MS