headers
rupert.thurner@gmail.com | 3 Apr 12:18
Picon
Gravatar

[Trac-dev] a lot of query links on one wiki page seem to be a performance hit


hi,

we use a low mhz platform for running trac, and notice a serious
performance hit when we put a lot of query links on one wiki page. we
notice the behaviour to the same extent for 0.10.4 and 0.11.

example:
5 links like [query:status=new|assigned|
reopened&keywords=~bla&type=task&order=priority 01] take one second
(i.e. 50 take 10 sec)

i tried it on the teo sandbox as well, but there it seems to be a lot
faster. so we need 2000 of the query links to have answer times above
10 sec. 2000 normal wiki links take 3-4 sec to answer. trac-hacks
needs approx 25 sec for the 2000 query links.

where this may be coming from?

kr, rupert.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 4 comments |
headers
Christian Boos | 3 Apr 12:31
Picon

[Trac-dev] Re: a lot of query links on one wiki page seem to be a performance hit


rupert.thurner <at> gmail.com wrote:
> hi,
>
> we use a low mhz platform for running trac, and notice a serious
> performance hit when we put a lot of query links on one wiki page. we
> notice the behaviour to the same extent for 0.10.4 and 0.11.
>
> example:
> 5 links like [query:status=new|assigned|
> reopened&keywords=~bla&type=task&order=priority 01] take one second
> (i.e. 50 take 10 sec)
>
> i tried it on the teo sandbox as well, but there it seems to be a lot
> faster. so we need 2000 of the query links to have answer times above
> 10 sec. 2000 normal wiki links take 3-4 sec to answer. trac-hacks
> needs approx 25 sec for the 2000 query links.
>
>   

This is http://trac.edgewall.org/ticket/6436 (Query links (eg [query: 
....]) amazingly slow).

> where this may be coming from?
>   

No idea, but from what you reported, this seems to be somehow fixed in 
recent trunks (teo is at r6772).
Would be interesting to bisect this.
(Continue reading)

Permalink | Reply | 3 comments |
headers
rupert.thurner@gmail.com | 3 Apr 15:40
Picon
Gravatar

[Trac-dev] Re: a lot of query links on one wiki page seem to be a performance hit


we run 0.11dev-r6737 ... but also on teo takes 4 times longer for
displaying a query link than for displaying other wiki links. is this
ok according to your experience given the string processing done?

rupert.

On Apr 3, 12:31 pm, Christian Boos <cb...@neuf.fr> wrote:
> rupert.thur...@gmail.com wrote:
> > hi,
>
> > we use a low mhz platform for running trac, and notice a serious
> > performance hit when we put a lot of query links on one wiki page. we
> > notice the behaviour to the same extent for 0.10.4 and 0.11.
>
> > example:
> > 5 links like [query:status=new|assigned|
> > reopened&keywords=~bla&type=task&order=priority 01] take one second
> > (i.e. 50 take 10 sec)
>
> > i tried it on the teo sandbox as well, but there it seems to be a lot
> > faster. so we need 2000 of the query links to have answer times above
> > 10 sec. 2000 normal wiki links take 3-4 sec to answer. trac-hacks
> > needs approx 25 sec for the 2000 query links.
>
> This ishttp://trac.edgewall.org/ticket/6436(Query links (eg [query:
> ....]) amazingly slow).
>
> > where this may be coming from?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Abrahams | 3 Apr 15:56
Picon
Picon
Favicon
Gravatar

[Trac-dev] Re: Correction


on Tue Mar 18 2008, Tim Hatch <trac-dev-AT-timhatch.com> wrote:

> If you answer "n" to quit and then "n" to creating a core file, it
> will continue (and seems to give reasonable information).
>
> On my FreeBSD box I get the same behavior as you by attaching without
> specifying the executable itself.  Try:
>
> gdb -p $pid `which python`

This trac process was occupying 400MB but 0% CPU when I stopped
it

  $ gdb -p 94603 `which python`
  GNU gdb 6.1.1 [FreeBSD]
  Copyright 2004 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
  Attaching to program: /usr/local/bin/python, process 94603
  ptrace: Operation not permitted.
  /usr/home/dave/94603: No such file or directory.
  (gdb) bt
  No stack.
  (gdb) 

--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Abrahams | 3 Apr 16:00
Picon
Picon
Favicon
Gravatar

[Trac-dev] Re: Correction


on Thu Apr 03 2008, David Abrahams <dave-AT-boost-consulting.com> wrote:

> on Tue Mar 18 2008, Tim Hatch <trac-dev-AT-timhatch.com> wrote:
>
>> If you answer "n" to quit and then "n" to creating a core file, it
>> will continue (and seems to give reasonable information).
>>
>> On my FreeBSD box I get the same behavior as you by attaching without
>> specifying the executable itself.  Try:
>>
>> gdb -p $pid `which python`
>
> This trac process was occupying 400MB but 0% CPU when I stopped
> it
>
>   $ gdb -p 94603 `which python`
>   GNU gdb 6.1.1 [FreeBSD]
>   Copyright 2004 Free Software Foundation, Inc.
>   GDB is free software, covered by the GNU General Public License, and you are
>   welcome to change it and/or distribute copies of it under certain conditions.
>   Type "show copying" to see the conditions.
>   There is absolutely no warranty for GDB.  Type "show warranty" for details.
>   This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)...
>   Attaching to program: /usr/local/bin/python, process 94603
>   ptrace: Operation not permitted.
>   /usr/home/dave/94603: No such file or directory.
>   (gdb) bt
>   No stack.
>   (gdb)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Boos | 3 Apr 16:41
Picon

[Trac-dev] Re: a lot of query links on one wiki page seem to be a performance hit


rupert.thurner <at> gmail.com wrote:
> we run 0.11dev-r6737 ... but also on teo takes 4 times longer for
> displaying a query link than for displaying other wiki links. is this
> ok according to your experience given the string processing done?
>   
>>
>>> example:
>>> 5 links like [query:status=new|assigned|
>>> reopened&keywords=~bla&type=task&order=priority 01] take one second
>>> (i.e. 50 take 10 sec)
>>>       

OK, links like [query:status=...] will require /some/ processing power, 
(query = Query.from_string(), then query.get_href()), whereas the other 
form of query links, i.e. [query:?status=...] will not, as it's already 
an part of an URL than only needs to be copied around (1). You may try 
the later form, and see if that makes a difference. If not, then it's 
something else, in the wiki lhref processing.

-- Christian

(1) - see http://trac.edgewall.org/wiki/TracQuery#UsingTracLinks for the 
exact difference between the two styles

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Hatch | 3 Apr 16:57
Favicon

[Trac-dev] Re: Correction


>   Attaching to program: /usr/local/bin/python, process 94603
>   ptrace: Operation not permitted.
>   /usr/home/dave/94603: No such file or directory.

It didn't actually attach to the process, I'm guessing you're not root
or the user trac runs under when you tried gdb.

I wonder if you're hitting http://trac.edgewall.org/ticket/7064 (giant
code blocks basically are really bad for performance, reallocating
memory a lot, and bringing that process to a halt).  Can you check for
any db rows over... say, 100KB?

Tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Christian Boos | 3 Apr 17:42
Picon

[Trac-dev] Re: a lot of query links on one wiki page seem to be a performance hit


Christian Boos wrote:
> rupert.thurner <at> gmail.com wrote:
>   
>> we run 0.11dev-r6737 ... but also on teo takes 4 times longer for
>> displaying a query link than for displaying other wiki links. is this
>> ok according to your experience given the string processing done?
>>   
>>     
>>>> example:
>>>> 5 links like [query:status=new|assigned|
>>>> reopened&keywords=~bla&type=task&order=priority 01] take one second
>>>> (i.e. 50 take 10 sec)
>>>>       
>>>>         
>
>
> OK, links like [query:status=...] will require /some/ processing power, 
> (query = Query.from_string(), then query.get_href()), whereas the other 
> form of query links, i.e. [query:?status=...] will not, as it's already 
> an part of an URL than only needs to be copied around (1). You may try 
> the later form, and see if that makes a difference. If not, then it's 
> something else, in the wiki lhref processing.
>   

Please try the following patch:
http://trac.edgewall.org/attachment/ticket/6436/cache-get_ticket_fields-r6792.diff

That fixed the performance issue for me, and I suspect this could help 
in other situations as well.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Thomas | 3 Apr 21:49
Gravatar

[Trac-dev] Re: Correction


On 4/3/08, Tim Hatch <trac-dev <at> timhatch.com> wrote:
>
>  >   Attaching to program: /usr/local/bin/python, process 94603
>  >   ptrace: Operation not permitted.
>  >   /usr/home/dave/94603: No such file or directory.
>
>
> It didn't actually attach to the process, I'm guessing you're not root
>  or the user trac runs under when you tried gdb.
>
>  I wonder if you're hitting http://trac.edgewall.org/ticket/7064 (giant
>  code blocks basically are really bad for performance, reallocating
>  memory a lot, and bringing that process to a halt).  Can you check for
>  any db rows over... say, 100KB?

It's also possible that you're hitting some Python "bugs" [1] triggered by
Genshi [2]. The Genshi ticket actually dsicusses two issues, one genuine
memory leak in Python's builtin groupby() and another covered by the
linked-to Python issue, where memory allocated to unicode objects is
never returned to the system.

The latter is "fixed" in Genshi r816 [3] and Trac r6757 [4], and the former
is fixed in Trac r6637 [5].

If you're not already running at least Trac r6637 and Genshi r816, you
should upgrade and see if your problem persists.

[1] http://bugs.python.org/issue2321,
[2] http://genshi.edgewall.org/ticket/190
(Continue reading)

Permalink | Reply | 0 comments |
headers
Noah Kantrowitz | 3 Apr 23:12
Picon
Favicon

[Trac-dev] Re: Private Tickets in 0.11


There is an initial port in a ticket. A nicer port will follow  
eventually.

--Noah

On Mar 25, 2008, at 8:51 AM, toivonens <at> gmail.com wrote:
>
> At Trac 0.10 I used PrivateTicketsPlugin. So, users had
> TICKET_VIEW_OWNER permissions and could see only their own tickets at
> the button "View Tickets".
> Now I use 0.11. And users havn`t button "View Tickets". I gave them
> REPORT_VIEW permissions and so they can see all tickets.
> But I want common user see tickets that has this user as owner. And I
> want user can`t see other's tickets.
> How can I do it at trac 0.11b1 ?
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |

Gmane