headers
rupert.thurner@gmail.com | 7 Aug 2009 18:23
Picon
Gravatar

[Trac-dev] trac performance: reload all plugins on every click really necessary ?


i am not enough python developer to judge this, but it looks so much
overload that on every click we have 160 lines caused by plugins in
our log file. is this really necessary?

2009-08-07 17:36:44,918 Trac[loader] DEBUG: Loading datefield.filter
from /opt/csw/lib/python/site-packages/TracDateField-1.0.1-py2.5.egg
2009-08-07 17:36:45,189 Trac[loader] DEBUG: Loading tracreposearch
from /opt/csw/lib/python/site-packages/tracreposearch-0.2-py2.5.egg
2009-08-07 17:36:45,223 Trac[loader] DEBUG: Loading newsflash.macro
from /opt/csw/lib/python/site-packages/TracNewsFlash-0.1-py2.5.egg
2009-08-07 17:36:45,335 Trac[loader] DEBUG: Loading tracwysiwyg from /
opt/csw/lib/python/site-packages/TracWysiwyg-0.2_r4353-py2.5.egg
2009-08-07 17:36:45,358 Trac[loader] DEBUG: Loading
ticketdelete.web_ui from /opt/csw/lib/python/site-packages/
TracTicketDelete-2.0-py2.5.egg
2009-08-07 17:36:45,415 Trac[loader] DEBUG: Loading iniadmin from /opt/
csw/lib/python/site-packages/IniAdmin-0.2-py2.5.egg
2009-08-07 17:36:45,449 Trac[loader] DEBUG: Loading
customfieldadmin.api from /opt/csw/lib/python/site-packages/
TracCustomFieldAdmin-0.2-py2.5.egg
2009-08-07 17:36:45,481 Trac[loader] DEBUG: Loading
customfieldadmin.customfieldadmin from /opt/csw/lib/python/site-
packages/TracCustomFieldAdmin-0.2-py2.5.egg
2009-08-07 17:36:45,514 Trac[loader] DEBUG: Loading announcerplugin
from /opt/csw/lib/python/site-packages/AnnouncerPlugin-0.2-py2.5.egg
2009-08-07 17:36:46,179 Trac[loader] DEBUG: Loading
TracDownloads.timeline from /opt/csw/lib/python/site-packages/
TracDownloads-0.2-py2.5.egg
2009-08-07 17:36:46,425 Trac[loader] DEBUG: Loading TracDownloads.api
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tim Hatch | 7 Aug 2009 18:38
Favicon
Gravatar

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?


On 8/7/09 9:23 AM, rupert.thurner <at> gmail.com wrote:
> 
> i am not enough python developer to judge this, but it looks so much
> overload that on every click we have 160 lines caused by plugins in
> our log file. is this really necessary?

1. IIRC you shouldn't get that that for every page load, you should get
it only when a trac process is starting up (so once per apache worker or
fcgi process, etc).
2. You have debug logging on. The point of debug logging is to log
everything that might be useful. If you've decided it's not useful,
change your log level down to info or warning.

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 | 0 comments |
headers
Christian Boos | 7 Aug 2009 18:39
Picon

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?


rupert.thurner <at> gmail.com wrote:
> i am not enough python developer to judge this, but it looks so much
> overload that on every click we have 160 lines caused by plugins in
> our log file. is this really necessary?

Well, assuming you're using latest Trac 0.11, I'd say one of these 
plugins is doing a "config.touch()" at every request, which triggers the 
reload of the whole environment at the next request.
Either grep the plugins sources for the above pattern, or identify the 
faulty plugin by re-enabling them one by one, starting with an 
environment with no plugins enabled. I'm pretty sure that you won't get 
this problematic behavior at first, unless you're using an old version 
of Trac which had such an issue (pre-0.11,  see r6893).

Then you'd want to fix your "r0" problems for some plugins, due to 
setuptools and svn 1.6, see the Notes in 
http://trac.edgewall.org/wiki/setuptools

-- Christian

--~--~---------~--~----~------------~-------~--~----~
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 | 5 comments |
headers
Remy Blank | 7 Aug 2009 19:06
Picon
Favicon

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?

Christian Boos wrote:
> Well, assuming you're using latest Trac 0.11, I'd say one of these 
> plugins is doing a "config.touch()" at every request, which triggers the 
> reload of the whole environment at the next request.

And this should give you a taste of what CGI was like ;-)

-- Remy
Permalink | Reply | 0 comments |
headers
rupert.thurner | 8 Aug 2009 12:31
Picon
Gravatar

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?


On Aug 7, 6:39 pm, Christian Boos <cb... <at> neuf.fr> wrote:
> rupert.thur... <at> gmail.com wrote:
> > i am not enough python developer to judge this, but it looks so much
> > overload that on every click we have 160 lines caused by plugins in
> > our log file. is this really necessary?
>
> Well, assuming you're using latest Trac 0.11, I'd say one of these
> plugins is doing a "config.touch()" at every request, which triggers the
> reload of the whole environment at the next request.
> Either grep the plugins sources for the above pattern, or identify the
> faulty plugin by re-enabling them one by one, starting with an
> environment with no plugins enabled. I'm pretty sure that you won't get
> this problematic behavior at first, unless you're using an old version
> of Trac which had such an issue (pre-0.11,  see r6893).

many thanks for the hint! the agilo plugin contained such touch, but i
am not sure if it was the cause as every process started by mod_wsgi
also causes a load as pointed out by tim before.

with the naked trac it looks much better now, the remote user is set
via apache.

2009-08-08 11:20:25,932 Trac[main] DEBUG: Dispatching <Request "GET u'/
wiki'">
2009-08-08 11:20:26,045 Trac[chrome] DEBUG: Prepare chrome data for
request
2009-08-08 11:20:26,065 Trac[perm] DEBUG: No policy allowed
rupert.thurner performing TRAC_ADMIN on None
2009-08-08 11:20:26,069 Trac[perm] DEBUG: No policy allowed
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Eads | 7 Aug 2009 17:04
Picon

[Trac-dev] Hello, Trac developers!


Hello, Trac development community!

I'm writing because I'm (tentatively) interested in becoming involved
in the Trac development community.

I've always really liked Trac, and insisted on it for several large
projects, but when I picked up the Trac 0.12 multirepo branch and
Mercurial plugin early this summer, and found the third party
ecosystem to be far more vital than it once was, it basically made my
head explode.  Trac has been my tool of choice for big coding
projects, but it seems that now that multiple repository support is in
the pipeline, Trac has tremendous potential as a knowledge management
and simple project management tool for the kinds of projects that I
work on.

I would like to start contributing to Trac and the discussion about
Trac.  I also don't want to parachute in, but this sure seems to be a
pretty friendly and smart community.  I've been reading the mailing
list archives and look through the proposals on the wiki, and
following the active development branches.  I've also started to
develop some themes and play around with hacking on Trac core.

To provide some context:  My two big projects these days are FreeGeek/
Chicago (http://www.freegeekchicago.org), and the Invisible Institute
(http://invisibleinstitute.com), which both need to combine knowledge
management, collaborative documentation / writing, light software
development, and simple project management.  Both groups are
"layperson"-heavy -- for each group, there's a small number (in the
case of Invisible Institute, it's just me) of highly technical folks,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christian Boos | 8 Aug 2009 17:39
Picon

[Trac-dev] Re: Hello, Trac developers!


Hello David,

David Eads wrote:
> Hello, Trac development community!
>
> I'm writing because I'm (tentatively) interested in becoming involved
> in the Trac development community.
>   

It's easy, really - just pick a few tickets you find interesting (or 
propose your own) and start sending patches ;-)

> <snip cool background ;-) >
>
>   * Working on a theme that uses the Blueprint css library and makes
> Trac look a little slicker.  I like the default theme *a lot* -- it is
> a great, straightforward default, better than most open source
> packages.  But I'm curious how it can be made more usable by the smart
> layperson. Using Blueprint has the added advantage, when mixed with
> div processors, of allowing very flexible layouts.  Because I don't
> know Trac well enough yet, the current incarnation of the theme is
> pretty unholy and hacked up, but there's a live demo at
> http://blueprintdemo.invisibleinstitute.com/ if anyone wants to see.
>   

Yep, that's interesting. We more or less have a revamp of the css in 
mind for some later release, see #5997 and #633.

>  * Experimenting with rewriting the notification system to be more
(Continue reading)

Permalink | Reply | 3 comments |
headers
ANdreaT | 8 Aug 2009 17:10
Favicon

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?


On Aug 8, 12:31 pm, "rupert.thurner" <rupert.thur... <at> gmail.com> wrote:
> On Aug 7, 6:39 pm, Christian Boos <cb... <at> neuf.fr> wrote:
>
> > rupert.thur... <at> gmail.com wrote:
> > > i am not enough python developer to judge this, but it looks so much
> > > overload that on every click we have 160 lines caused by plugins in
> > > our log file. is this really necessary?
>
> > Well, assuming you're using latest Trac 0.11, I'd say one of these
> > plugins is doing a "config.touch()" at every request, which triggers the
> > reload of the whole environment at the next request.
> > Either grep the plugins sources for the above pattern, or identify the
> > faulty plugin by re-enabling them one by one, starting with an
> > environment with no plugins enabled. I'm pretty sure that you won't get
> > this problematic behavior at first, unless you're using an old version
> > of Trac which had such an issue (pre-0.11,  see r6893).
>
> many thanks for the hint! the agilo plugin contained such touch, but i
> am not sure if it was the cause as every process started by mod_wsgi
> also causes a load as pointed out by tim before.

Hi Rupert,
 I had a chat with Christian today about the touch thing, and pointed
me here to have a look at this thread :-) You are right Agilo uses the
touch() in two specific situations, when the types definition changes
(because you add your own new type for example, or changed and
alias... or add some additional properties). We are very sensible to
performance issues, and we will investigate more on the flow
generating the reload of the plugins, that may be dependent on many
(Continue reading)

Permalink | Reply | 2 comments |
headers
rupert.thurner | 9 Aug 2009 06:32
Picon
Gravatar

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?


can the times between the debug statements also taken as performance
points? if yes, then  the following is slow here:
 1. retrieving the session id
     taking up to 5 seconds, on the third click coming down.
 2. update wiki page index
     taking up to 5 seconds, and happening quite often when only
clicking once
     there is "            if now > self._last_index_update +
WikiSystem.INDEX_UPDATE_INTERVAL:"
     which is set to 5 sec  - but for us 10 minutes are sufficient i
guess.

log excerpt 1, one click on main wiki page:

2009-08-09 00:31:09,282 Trac[main] DEBUG: Dispatching <Request "GET u'/
wiki'">
2009-08-09 00:31:09,700 Trac[api] DEBUG: action controllers for ticket
workflow: ['ConfigurableTicketWorkflow']
2009-08-09 00:31:09,868 Trac[svn_fs] DEBUG: Subversion bindings
imported
2009-08-09 00:31:09,912 Trac[chrome] DEBUG: Prepare chrome data for
request
2009-08-09 00:31:10,151 Trac[api] DEBUG: Updating wiki page index
2009-08-09 00:31:10,180 Trac[session] DEBUG: Retrieving session for ID
'rupert.thurner'
2009-08-09 00:31:12,958 Trac[formatter] DEBUG: Executing Wiki macro
TracNav by provider <tracnav.tracnav.TracNav object at 0x16d6eb0>

log excerpt 2, one click on timeline:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Boos | 9 Aug 2009 11:38
Picon

[Trac-dev] Re: trac performance: reload all plugins on every click really necessary ?


rupert.thurner wrote:
> can the times between the debug statements also taken as performance
> points? if yes, then  the following is slow here:
>  1. retrieving the session id
>      taking up to 5 seconds, on the third click coming down.
>  2. update wiki page index
>      taking up to 5 seconds, and happening quite often when only
> clicking once
>      there is "            if now > self._last_index_update +
> WikiSystem.INDEX_UPDATE_INTERVAL:"
>      which is set to 5 sec  - but for us 10 minutes are sufficient i
> guess.
>
> log excerpt 1, one click on main wiki page:
>
> 2009-08-09 00:31:09,282 Trac[main] DEBUG: Dispatching <Request "GET u'/
> wiki'">
> 2009-08-09 00:31:09,700 Trac[api] DEBUG: action controllers for ticket
> workflow: ['ConfigurableTicketWorkflow']
> 2009-08-09 00:31:09,868 Trac[svn_fs] DEBUG: Subversion bindings
> imported
> 2009-08-09 00:31:09,912 Trac[chrome] DEBUG: Prepare chrome data for
> request
> 2009-08-09 00:31:10,151 Trac[api] DEBUG: Updating wiki page index
> 2009-08-09 00:31:10,180 Trac[session] DEBUG: Retrieving session for ID
> 'rupert.thurner'
> 2009-08-09 00:31:12,958 Trac[formatter] DEBUG: Executing Wiki macro
> TracNav by provider <tracnav.tracnav.TracNav object at 0x16d6eb0>
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane