• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Primefaces Live scrolling taking long time with large dataset

 
Greenhorn
Posts: 5
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi I have a primefaces datatable with about 52000 records to be fetched.Since it is a large dataset,i tried using live scrolling feature of primefaces with scroll rows equal to 20.THe number of columns is 53.The table also has filtering and sorting feature on its each column.Still i am not satisfied with the performance of the table.It takes about 15 secs for the page to load,worst thing is that it takes about 65 secs for the next set of 20 records to be loaded on reaching the end of scrolling.

Just for testing i reduced the total number of records to 25000 and the preformance improves with scroll time of 29 secs.I am really not able to understand why it is taking this much time when i am displaying only 20 records at a time.The total number of records should not have affected the performance.

Can someone please suggest how to improve the performance.I cannot implement pagination for this since my customer don't want it :( .Thanks in advance

My JSF code snippet



My Managed bean
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As usual, I didn't get all that on the first try, so I'll stumble around blindly, offering suggestions and we'll see how we can work things out from there.

First of all, Request Scope is almost 100% useless in JSF. JSF is heavily invested in Postback processing, and request-scope objects are completely destroyed and re-created with each posting. With very rare exceptions, you should always be using View or Session scope. In the case where you are using one of JSF's model classes (SelectItem or DataModel), Request scope is 100% useless, since the re-created models will lack cursor context.

So much for the UI side.

On the database performance side, pulling thousands of records is usually going to be a noticeable delay, certainly. For that matter, if you pull them into a session-scope (or view-scope) object, it's also going to require typically a big chunk of RAM, which will probably be virtual, thus putting you at risk for excessive Virtual Memory paging (thrashing). For Request scope, of course, you're going to be pulling them in for EACH time that the request object is re-created. Ouch!

I'm going to stop for a moment and wag my finger at your user. I've done apps that had to be able to return thousands of rows, but in practical terms, after the first hundred or so, my eyes begin to water. Sweeping up everything in sight may be good for the NSA, but for ordinary people, it would be better to be able to home in on items of specific interest.

However, if that's what they insist on (sigh). Ordinarily one would use the slice-and-dice approach to information retrieval. Although there's no official SQL definition for making a selection, then returning for subsets of it, many databases have something that will do that. and it's relatively straightforward to use on paged displays.

In the case of continuous scrolling, you'll need something more subtle, though. Basically, what I'd look at is a subclass of the JSF DataModel that supports virtual rows. That is, to the dataTable, it appears to wrap a complete table of all the matching rows. But in reality, it does an on-demand fetch and cache of only the rows that people are actually viewing. For performance reasons, you may want to use the slice-and-dice technique to grab, say, 20 rows at a time, but only grab rows that people actually pull into their view.

I can't give specific details, since this isn't a trivial task and I don't have any code lying around. But I think that you'll find that this strategy will work for you.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic