Home Blog : Speed up Collaboration Project Explorer Pagination
󰀄

There’s a way in ALUI Collaboration to tweak how pagination functions, and it could mean big performance gains in Collaboration Project Explorer. Basically, you can allow lists of items (such as documents) to be pre-loaded by Project Explorer, instead of having a small part loaded every time a user paginates through them.

The setting is called serverSidePagination and can be found in %PTHOME%ptcollab4.xsettingsconfigconfig.xml, and is at plumtree/config/jscontrols:

   <serverSidePagination enabled=”yes/>

If you change this value to no, it’ll take a little longer to load initial pages that have long lists on them, but the payoff is that end users could get a very big performance gain when clicking through the various pages, because Project Explorer no longer has to make an HTTP request back to the server every time a user clicks ‘Next Page’.

To test this out, I created 130 documents in a test project and used TcpTrace to monitor the traffic between the portal and collab.

The result: The first time the list was loaded, the HTTP response from Collab was twice as large and took a little longer to come back, but there were no subsequent requests at all when paginating through the list so pagination was noticably faster. Unless there are some very large collab projects in your environment (which would cause the initial page load to be too long), I’d give this a shot, as it could potentially eliminate a lot of extra requests back to the server.

By the way, I’m not even going to give you the standard disclaimer about this being undocumented and unsupported: See the Collab Appendix for the documentation:

serverSidePagination: Enables and disables server-side pagination of Explorer controls to improve performance when there are many items. Valid values are yes and no.

If you’re interested, technical analysis after the jump…

To test out the peformance gains (or losses) of this change, I monitored traffic between the Portal and Collaboration. With ServerSidePagination turned ON (default setting):

… and with it turned OFF:

These results show:

  1. the first request (opening the project itself) is the same.
  2. the second request (loading the initial “Documents” tab with 130 documents in it) is twice as large when serverSidePagination is off, and took about 20% longer (since I was testing on a local machine, the larger size didn’t affect my test as much as it would have over a slow network)
  3. the third and fourth requests can be ignored; they’re just .js file requests
  4. Notice that with the setting turned off, there were no other requests to Collab as I paginated through the list; with the setting turned off, a 100k+ response was needed for every page of 15 items

Note that with the setting off, the initial request is twice as big, but with the setting on, there was about 3x as much traffic going “over the wire” if a user paginates through the whole list. So your mileage may vary depending user behavior and how many documents are in your average project; use with care…

Comments

Write a comment:

*

Your email address will not be published.

󰁓
󰀰 󰀩 󰀭 󰀎