The Future of Performance: Scaling

David Lawrence dkl at redhat.com
Mon Jan 5 22:27:53 UTC 2009


Max Kanat-Alexander wrote:
> On Mon, 05 Jan 2009 16:29:12 -0500 David Lawrence <dkl at redhat.com>
> wrote:
>   
>> Now that we allow search engines to index bugzilla.redhat.com using 
>> sitemap index files,
>>     
>
> 	Interesting, I'd like to know if that's something we could port
> upstream.
>
>   

https://bugzilla.redhat.com/show_bug.cgi?id=427004

>> This statement is executed everytime Bugzilla->login is called
>> without auth data
>>     
>
> 	See, that's the problem, there, and it's not exactly the bug
> that LpSolit pointed out. We're just calling it too often. It used to
> happen when generated versioncache, I believe, since we did that every
> hour, but that was the only thing that Bugzilla did regularly.
>
>   
>> To solve the issue we are moving that code to a separate script that 
>> will be ran once a night to clean up expired cookies in the
>> logincookies table. By commenting out that line in Bugzilla::Auth we
>> saw the database load decrease and the slaves were able to get caught
>> up. Does this sound like something that would be useful to the
>> upstream and a bug/patch generated?
>>     
>
> 	Yeah, definitely, although I think for upstream we'd just want
> to somehow make the DELETE less common, not move it to a separate
> script. (I just don't want every single Bugzilla installation to have
> to run a separate script every night, if they don't want to.)
>   

There is also the collectstats.pl script but even that may not be ran 
nightly
unless the admin chooses to.

What if we first did a select to see if there would be any cookies older 
than
30 days returned and only then do a delete? The select at least would not
block like the delete would and if this worked it would only in theory run
once every 30 days or I may be wrong.

Dave

-- 
David Lawrence, RHCE  dkl at redhat.com
------------------------------------
Red Hat, Inc.    Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606




More information about the developers mailing list