Seeking solution for XSP submit latency

Question

I have a xpage where I have dependent combo-boxes. When I select first combobox, it partially refreshes second combobox, which is populated by huge number of keywords (approx. 10K looking up from view). This action takes a lot of time, owing to which I decided to use XSP.submitlatency.

So, I created scriptblock and added this code:

XSP.addOnLoad(function() { //increase Ajax request timeout to 35 seconds XSP.submitLatency = 35 * 1000; });

This worked fine but then all other partial refreshes take 15 seconds.

Then I tried using submitlatency=15000 with first combobox instead of using on addOnLoad(). Along with above I used submitlatency=2000 when I click for any other partial refresh. But couldn't find the expected results. Normal behaviour of page is gone and other partial refreshes seem NOT to work.

Please help ! Or suggest if there is better alternative to deal with this problem to enhance responsive time.

Answer 1

A combo Box with 10k of entries is a UX disaster waiting to happen. Use a Dojo grid with a local data source or any other bigger mechanism. Local storage is your friend

Answer 2

A combobox thas tries to load 10K entries each time user selects sth is very bad idea. Even if You manage somehow to make the timeout longer still this operation is too heavy and Your app will not scale (few users using this combo at the same time will bring app to its knees).

You should not mess with latency but change the way You pass data to combobox. Learn about dojo data stores:

http://dojotoolkit.org/reference-guide/1.9/quickstart/data/usingdatastores.html

Then find out how combobox uses them to retrieve data.

With this knowledge You will be able to either:

• cache the data on app start in browser (if the type of data is quite static - for example names of cities)
• use dojo query store to get only a subset of data based on user input and let domino indexes do the hard work

Bit of advice here - Domino is not very efficient with handling large amounts of data out of box. You can force it to work with millions of records but this needs a lot of work and knowledge so better think this through before Your app goes to production and simply stops working.

Answer 3

Before 8.5.2 submitLatency was set to a default of 6 seconds. The default from 8.5.2 on is 20 seconds. Changing XSP.submitLatency changes it for everything. It is also a time out, so unless your other calls were slow to begin with, it should not increase the time to submit.

You can try changing 'asp.ajax.renderwholetree' to see if that helps. Here is the comments on that.

# This property defines if the JSF tree should be
# completely processed during the render phase,
# including the components that are not rendered. When set to false
# it gives better performance but with potential side effects
# if some components are changing data during the render phase 
# (which # should be avoided anyway)
#xsp.ajax.renderwholetree=true

This value defaults to true in 8.5.2 and later.

Other then that, I would recommend using the XPages Toolbox to debug the application. The training material is contained in the XPages Masterclass:

Answer 4

The best way to deal with this is to use a loading screen/standby dialog. This prevents that the user clicks on other buttons/links/whatever during the partial refresh AND informs him that something happens. This helps to get a better user experience.

See here for a solution: http://openntf.org/XSnippets.nsf/snippet.xsp?id=standby-dialog-custom-control

Btw. 10k keywords in a combobox? As a user I would shoot the developers ;-)

Answer 5

Serving up to 10k of keywords to a user is something you don't want to be happening. Especially not inside a combobox. They are not designed for such a big pile of data. Can't you change the design in such a way that the first combobox will refresh a data table control in which the user can select what they want? On a datatable you can add a pager and ofcourse some filters. More info about the datatabhere