Trac issue tracker is slow

[William Siegrist]

On Jun 20, 2008, at 11:45 PM, Ryan Schmidt wrote:

> On Jun 20, 2008, at 11:21 PM, William Siegrist wrote:
>
>> On Jun 11, 2008, at 3:31 AM, Ryan Schmidt wrote:
>>
>>> The Trac issue tracker is very slow, and it has been for weeks,  
>>> maybe
>>> months.
>>>
>>> View a ticket: 10 seconds
>>> Preview a change to a ticket: 10 seconds
>>> Make a change to a ticket: 14 seconds
>>> Show the New Ticket form: 6 seconds
>>> Show the Custom Query page: 10 seconds
>>> Find all non-closed tickets with "mysql" in the summary: 19 seconds
>>
>> All of the above invoke the restrict_owner code which gives us the  
>> selector for owner instead of a text box. The way Trac generates  
>> that selector is very inefficient, and the code in v0.11 (due out  
>> this weekend) doesnt look much better.  The feature just wasnt  
>> intended for such a large selector it seems.
>
> Thanks for looking into this and finding the cause.
>
>> I've tried a few things to see what could help, and the only thing  
>> that makes a difference is switching to the textbox. In fact, the  
>> tickets load as fast as every other part of trac when using the  
>> text field.
>
> Is there a way to hook into Trac and just give it a pre-made menu to  
> display there? Or could we somehow post-process Trac's page to fill  
> in the menu ourselves? I already posted a script to get the list of  
> maintainers out of the portfiles (in some ticket) which could be run  
> e.g. daily and turned into a ready-made menu.inc.html that could be  
> put into the right place in the Trac pages, if there were a hook  
> with which to do that.
>

Its not pluggable using the usual Trac API. I also remembered the  
script you wrote to try and populate the database, but my tests  
indicated that its slow with any useful dataset.


>> The benefit of the text box, aside from performance, is that people  
>> can assign tickets to users to prompt for more info, and tickets  
>> can be assigned to maintainers who are not committers.
>>
>> The bad part is having to type in the maintainer's or user's name.  
>> Its pretty easy to find that info, via the port command or the  
>> ticket page, but there's a chance for typos if people dont copy/ 
>> paste.
>
> Is it really possible to assign a ticket to a person who is not  
> registered in Trac?
>

Yes, the text box really takes any text I believe. This is possibly a  
product of the Trac philosophy of staying out of the way of  
development process in that people might want to assign tickets to  
psuedo-people, like "Intern1" or "To be Hired". But I'm just  
speculating.


>> So let me know if this change is worth the performance.  If some  
>> devs want to see the difference, you can ping me in IRC so I can  
>> switch the option, let you load a few of these pages, and then  
>> switch back. Its quite noticeable.
>
> Absent a way to build the menu ourselves, my vote would be to switch  
> to a text box. I usually copy/paste the maintainer's email address  
> from the "port info" output anyway, since we never got the full list  
> of maintainers in the drop down box.
>
> [thinks for a minute]
>
> I mean, we could even do it with JavaScript. Make Trac output a text  
> box, which is what people would see if JavaScript is off. And write  
> a JavaScript function which would swap that out for a drop-down menu  
> with our list of maintainers. If we can use our own templates with  
> our own links and graphics (which we clearly can) then we can also  
> have our own JavaScript code run on the page.
>
> Or instead of swapping the text box for a drop-down, we could use  
> one of those type-ahead auto-fill-in text box extension thingies.  
> Umm... I could probably whip something like that up for you.
>

Yes, javascript could help us with a static list. The auto-complete  
would be  I suppose. We use jquery and interface already, so there's  
probably something in there to help:

http://interface.eyecon.ro/

(I see it has an autocomplete demo, but their website seems broken as  
of this email).

This would involve a little bit of engineering and maintenance and add  
one more periodic job to watch over. So the text box is still the easy/ 
quick fix. But if people hate the text box, I can do the javascript  
option. Its not too unreasonable given whats already been done to  
integrate Trac with the rest of MacOSForge.

-Bill





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080621/550dff9b/attachment.p7s