Jerry: Jacob's note (see below) already says this would be a problem, but he has also mentioned a way to solve your problem; check if that works for you. Store the records in a session variable (that's right, session, instead of request makes sense here!!) and display just 20 or so records at a time. You will have to see if this is feasible.. it will depend on how "strong-big" your server is, etc..:)
Regards, Geeta Jerry Jalenak wrote: > In my application I often return large amounts of data - for instance, a > single user may have access to as many as 8500 accounts; each account may > have several hundred detail records associated with it. I've solved my > initial problem of being able to return thousands of records (for instance, > I can return almost 48,000 detail records in a little under 5 seconds), but > the problem I have now is that it takes FOREVER for the jsp to render. I > mean, I've waited over an hour for this thing to complete. Does anyone have > any tips on improving / optimizing the performance of a compiled JSP? I'm > using Tomcat 5.0.18 Stable with J2SDK 1.4.1_02.... > > Thanks! > > Jerry Jalenak > Development Manager, Web Publishing > LabOne, Inc. > 10101 Renner Blvd. > Lenexa, KS 66219 > (913) 577-1496 > > [EMAIL PROTECTED] > > > -----Original Message----- > > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 03, 2004 1:39 PM > > To: Struts Users Mailing List > > Subject: RE: Best way to handle big search results.. > > > > > > We have to work with search results that are sometimes 1000+ > > items in size. > > In addition, much of the information we have is not keyed so > > we cannot say > > give results between id 2000 and id 20020. > > > > Some things I found to help with search results where we did > > do in memory > > sorting/paging were: > > > > 1. Create view-specific lightweight objects to be pulled from the DB > > 2. Memory allowed, it's faster to pull them all at once than lazy load > > 4. The real cause of some of our performance problems were > > the JSP's/HTML in > > rendering a huge list to the client vs. only showing 20 at once. > > > > > > To handle this, I created a SearchResultListAdaptor that > > could sit in the > > session and handle paging (if anyone wants to argue session > > scope with me, > > bring it on--). The SearchResultListAdaptor then contained > > the behavior of > > sort order/paging, etc. Sorting was done via bean property using a > > BeanUtilsComparator. So my SearchResultListAdaptor could > > then work with an > > list of beans. > > > > Best Regards, > > Jacob > > > > -----Original Message----- > > From: Arne Brutschy [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 03, 2004 12:57 PM > > To: Struts Users Mailing List > > Subject: Best way to handle big search results.. > > > > Hi, > > > > I'm looking for the best way to handle big search results. > > > > Setting: the user can search for other users in the ldap > > directory. This > > might return a long list of results (~40.000 entrys). Sadly, OpenLDAP > > doesn't support server-side sorting, so I have to sort the results > > myself. I want to display 20 items per page, and the user can browse > > through these results. > > > > What is the best way to handle these result object? Sorting once and > > storing/caching it in the session or searching and sorting every time > > the user requests a new page of results? > > > > Any thoughts/experiences? > > > > Regards, > > Arne Brutschy > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > This transmission (and any information attached to it) may be confidential and > is intended solely for the use of the individual or entity to which it is > addressed. If you are not the intended recipient or the person responsible for > delivering the transmission to the intended recipient, be advised that you > have received this transmission in error and that any use, dissemination, > forwarding, printing, or copying of this information is strictly prohibited. > If you have received this transmission in error, please immediately notify > LabOne at the following email address: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
