Re: Maximum results to return from query

[Olav Vitters <olav bkor dhs org>]

On Mon, Dec 05, 2005 at 09:32:25AM -0500, Luis Villa wrote:
> On 12/5/05, Elijah Newren <newren gmail com> wrote:
> > > My question: What is the maximum number of bugs you would ever want to
> > > see as a query result? I'm guessing 2000.
> >
> > The only time I ever have thought that more than about 250 bugs would
> > be useful from buglist.cgi was when I was trying to get a count of how
> > many bugs of a particular type existed.  I bet others use it the same
> > way.
> 
> I know I do, for basic stats, and have gotten meaningful answers in
> the tens of thousands- see, for example, my blog post of yesterday.

I'll implement so that you can add a &limit=some_high_number to the
query. That actually is standard Bugzilla 2.20 stuff, but I never knew
it existed. Whithout the $limit=some_number it'll retrieve the 2000 (or
whatever number).

Oh regarding the 2000 -- I know I use a buglist with 1700 or so bugs and
then just try various keywords to find a dupe.

> > Given the existence of browse.cgi to satisfy most such basic
> > questions (and their ability to ask us when they have more advanced
> > questions),
> 
> > I think the limit could be a lot lower than 2000, though
> > 2000 does definitely seem safe.
> >
> > What'd be really cool is if we could have a way to have queries that
> > have taken longer than N minutes automatically be terminated.  I have
> > no clue how we'd do that, though.
> 
> That seems like a better approach, at least in theory. But yeah, I
> don't know how we'd implement it either.

Something with SIGALARM and stuff.. hopefully I can find an example
somewhere. I know the sysadmins want something on Apache level (some
blog processes also sometimes consume all CPU power and also I/O).

> Olav, do we know for certain that the long running queries were blank
> ones? ISTR that those take a fairly short time for the query to return
> and a long time to render in the browser (which makes it look like it
> is taking a lot of horsepower on the server), and that the surest way
> to hose the box is with a very complicated query that only returns a
> few bugs, not a broad one that returns lots of bugs.

100% certain. I catted /proc/$PID/environ of the processes that hanged.
The environment variables contain the query part (I think PATH_INFO,
not too sure though).


-- 
Regards,
Olav