Grid Performance Issues | Loading from DB on demand


We are testing the performance of the dhtmlgrid based on an estimated maximum number of records and columns that will be displayed on our grids.

These estimations are a maximum of 35,000 rows in a grid with 35 columns.

Our database calls alone are causing some performance issues, so we would like to call the database multiple times to retrieve a subset of rows (as required), and use these results in combination with the paging functionality provided with dhtmlx.

To achieve this we will be passing back a new xml to the grid each time a new page number is selected, containing the rows for that page number only. Ideally any page already visited will remain unchanged and will retain any changes already made to those rows.

These are the steps taken to try and achieve this:

  1. Initialize the Grid with Paging enabled.
  2. Load the grid with the rows for page 1 based on the number of rows per page (i.e. call the database and retrieve rows 1-30 if 30 items per page)
  3. Once the grid has been loaded using dhtmlxGrid.loadXML(urlOut), set the total number of rows by setting dhtmlxGrid.rowsBuffer.length. This updates the available page numbers.
  4. When a subsequent page number is clicked, make a call to the database and retrieve those records.
  5. Marshall these results to XML and update these to the grid using dhtmlxGrid.updateFromXML(urlOut);

The above appears to work fine - the records are displayed as expected but when I attempt to edit any cell on a page beyond 1, the page reloads automatically at page 1 again.

Is there a way to load only the required records into the dhtmlxgrid as you need them that will allow you to retain edits on other already loaded pages? Or do you have to use server side components such as those provided with dhtmlxConnector?


Default dynamic paging works in the same way as you need.

  • enable paging in grid
  • load grid, with xml for first page, which have total_count attribute, with total number of rows.
<rows total_count="10000">

As result grid will show all pages in pager, and when not-loaded-yet page is selected - it will send request to server side for extra data.

If you are using connector, you need just add one line to server side code


where 30 - how much rows must be loaded initially ( size of first page in your case )

Thanks for this.

Just a couple of follow up questions…

I can see now that when I select a new page number there is an automatic call back to the server using the same method call used to retrieve the details for the first page (we are using struts and it is calling the same method in the Action class).

I can see a “count” parameter in the request which seems to provide the number of rows per page. How do I find out what the page number is to calculate the rows required based on the page number? Can this be added to the request also?

Also, for some reason I seem to be getting an infinite number of calls back to the server when I select another page number. Can you confirm the following XML struture to rule that out as a cause:

Initial call to retrieve page 1 details (total 30 rows):

<?xml version='1.0' encoding='iso-8859-1'?> 99419 7916 10 2 2.88 8.35 cmadmi 2012-03-27 15:27:45.0 Y 9 ....

Subsequent calls to any other page number (total 30 rows):

<?xml version='1.0' encoding='iso-8859-1'?> 99419 5799 26 13 17.6 21.71 cmadmi 2012-03-27 15:27:45.0 Y 12 ....


By default grid sends only the starting position and requested count of rows ( pos and count parameters ), you can get page as pos/page_size

The response XML must contains pos attribute on the top tag

<?xml version='1.0' encoding='iso-8859-1'?> <rows pos="20"> <row id="5799"> <cell>99419</cell> <cell>5799</cell> <cell>26</cell>

pos is equal to the request parameter ( it will instruct client side code, at which position new rows must be added )

If response has not pos attribute, or it is invalid - it can cause problem similar to one in your case. As client side code will repeat data loading operations while data for currently visible page will not be loaded.