Some things that come to mind: - Force the use of a preference server, force the value of max returned entries to 1000 or the likes - Set a hard limit on the server for the max number of entries returned from a get... - Don't give users access to search regular forms (front-end things with display only forms)
Axton Grams On Tue, Jul 22, 2008 at 3:25 PM, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote: > ** > > Hi everyone: > > > > I wanted to get everyone's take on this thorny issue…I know this matter has > been discussed many times before, but I wanted to put a new twist on it. > > > > Specifically, I wanted to get anyone and everyone's thoughts on the problem > of unqualified searches in a large enterprise. Specifically, suppose the > following: Suppose you have a custom app being used in a very large > environment. Suppose in that environment you have established a ticket > isolation system by setting hidden fields on the form on SEARCH. Tickets > are isolated by every company within the enterprise. > > > > Now, each company has in excess of 150,000 tickets, and there are 20 > companies. The problem is, techs are accidentally clicking the SEARCH > button without any qualification…kicking off what is *seemingly* an > unqualified search. But the search is not truly unqualified because fields > are getting set on SEARCH to effect the ticket isolation. But the problem > remains – such a search goes out and attempts to fetch 150,000+ tickets. > Several techs accidentally doing this at once (we have 800+ techs, so the > possibility of techs doing this is pretty high) causes the server to slow > way down. > > > > Thoughts on how to minimize this issue? Hopefully I've described the problem > well enough. > > > > TIA, > > Norm > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
