Search This Blog

Sunday, January 5, 2014

Bad performance of XPages REST component with filtering enabled in XPiNC

Hi

Recently I worked on XPages based application where I used also Sencha Ext JS because of nice looking grids with many UI features on board.
The application had to work either in Web or in IBM Lotus Notes rich client.

If you familiar with Sencha Ext JS you may know that it uses MVC pattern and you need to define models, views, controllers and in case of grids you need data store also.
I used XPages REST control as a source for my Sencha data store that relied on Notes View in its turn.

During testing of that application I noticed that reading data for Sencha data store through XPages REST control worked much slower in XPiNC than in Web. I mean MUCH slower.
It wasn't too obvious when I tested it with a good connection to the Domino server but when I tried to test it on remote server with worse connection I experienced a huge difference in performance between Web and XPiNC.

After some hours of investigation I found the reason: XPages REST control works badly in XPiNC when you use any filtering option, like "keys", "search" etc. See description below...



F.x. if you have XPage "RestService.xsp" with a REST control like below

<xe:restService id="restService1" preventDojoStore="true" pathInfo="getdata">
<xe:this.service>
<xe:viewItemFileService defaultColumns="true" count="2000" viewName="Main" systemColumns="103" keys="10">
</xe:viewItemFileService>
</xe:this.service>
</xe:restService>

and you use it as a data source for Sencha grid data store (notice, I used Sencha Ext JS framework)

<xp:view xmlns:xp="http://www.ibm.com/xsp/core">

<script type="text/javascript" src="ext-4.2/ext-all.js"></script>
<xp:this.resources>
<xp:styleSheet href="ext-4.2/resources/css/ext-all.css"></xp:styleSheet>
</xp:this.resources>

<xp:button value="Call My REST service" id="button1">
<xp:eventHandler event="onclick" submit="false">
<xp:this.script><![CDATA[var t1 = new Date();
Ext.Ajax.request({
method: 'Get',
timeout: 90000,
        url: 'RestService.xsp/getdata',
        success: function(response, opts) {
 
             var obj = Ext.JSON.decode(response.responseText);
             console.dir(obj);
             var t2 = new Date;
             Ext.MessageBox.alert('', 'received ' + obj.items.length + ' records. Took time: ' + ((t2 - t1)/1000));
   },
   failure: function(response, opts) {
 alert('error');
      console.log('server-side failure with status code ' + response.status);
   }
});]]></xp:this.script>
</xp:eventHandler>
</xp:button>
</xp:view>

then time that is required to retrieve data through REST control is significantly less in Web against Notes (approximately is less than 4 times):

Web
Notes client

These screens I made on a workstation that is in a local network with Domino server, so actually retrieving time is very low in both cases but even now you can see the difference that becomes more noticeable when you have worse connection.

However, if we remove any filtering options from REST control then time for retrieving data is almost the same for both Web browser and Notes client:

<xe:restService id="restService1" preventDojoStore="true" pathInfo="getdata">
<xe:this.service>
<xe:viewItemFileService defaultColumns="true" count="2000" viewName="Main" systemColumns="103" keys="10">
</xe:viewItemFileService>
</xe:this.service>
</xe:restService>

Web
Notes client

You may also notice that time used by Notes client for getting 2000 records w/o filtering is less then time for getting 300 records with filtering enabled.

This is very strange. Why REST control with filtering enabled works so badly in Notes client against Web browser if both work the same without any filtering enabled? Very strange.

If you have any idea - please let me know.

If you want to play with my example, you can download if here.

1 comment:

  1. Have you tried Ext-ND? It automate the building the column model for the grid from the design of the view and get the data with readviewentries.

    ReplyDelete