Jacob / Geeta - Thanks for the responses. The business requires that each account / detail record set be placed in an independantly pagable/sortable table, so I'm using the <display /> taglib to handle this. For relatively small numbers (say up to a 100 accounts or so) the performance is really pretty good. I'd like to be able to restrict the date range that a user can specify, but again, business requirement states that 'the user must be able to browse upto 90 days worth of data'. I've tried to explain that, for some of these large clients this simply isn't going to work. I was hoping (8-) ) that there was a setting in Tomcat that I may have missed (I've already set up Tomcat as a 'production' environment).....
I don't know if it makes a difference, but I have yet to move to the EL tags - I'm still using the old Struts taglibs for things like <logic />, etc. Has anyone benchmarked the performance between these two approaches? Jerry Jalenak Development Manager, Web Publishing LabOne, Inc. 10101 Renner Blvd. Lenexa, KS 66219 (913) 577-1496 [EMAIL PROTECTED] > -----Original Message----- > From: Geeta Ramani [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 04, 2004 10:33 AM > To: Struts Users Mailing List > Subject: Re: Best way to handle big search results.. > > > 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] > > 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]
