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:
the funny thing the double entry, the second time happening while the
page is already displayed on the browser.

2009-08-08 23:50:33,749 Trac[main] DEBUG: Dispatching <Request "GET u'/
timeline'">
2009-08-08 23:50:33,807 Trac[session] DEBUG: Retrieving session for ID
'rupert.thurner'
2009-08-08 23:50:35,841 Trac[chrome] DEBUG: Prepare chrome data for
request
2009-08-08 23:50:36,049 Trac[api] DEBUG: Updating wiki page index
2009-08-08 23:50:41,081 Trac[api] DEBUG: Updating wiki page index
2009-08-08 23:50:45,150 Trac[main] DEBUG: Dispatching <Request "GET u'/
timeline'">
2009-08-08 23:50:45,197 Trac[session] DEBUG: Retrieving session for ID
'rupert.thurner'
2009-08-08 23:50:51,241 Trac[chrome] DEBUG: Prepare chrome data for
request
2009-08-08 23:50:51,607 Trac[api] DEBUG: Updating wiki page index


sqlite> select * from session where sid = "rupert.thurner";
rupert.thurner|1|1249737873
sqlite> select * from session_attribute where sid = "rupert.thurner";
rupert.thurner|1|timeline.daysback|30
rupert.thurner|1|timeline.filter.changeset|1
rupert.thurner|1|timeline.filter.milestone|1
rupert.thurner|1|timeline.filter.ticket|1
rupert.thurner|1|timeline.filter.wiki|1
sqlite> select count(*) from session;
26573
sqlite> select count(*) from session_attribute;
27626


On Aug 8, 5:10 pm, ANdreaT <[email protected]> wrote:
> On Aug 8, 12:31 pm, "rupert.thurner" <[email protected]> wrote:
>
>
>
>
>
> > On Aug 7, 6:39 pm, Christian Boos <[email protected]> wrote:
>
> > > [email protected] 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
> others connections/references with other modules.
>
>  I had a look today again, while fixing another bug, and I have noted
> down a couple of FIXME... so there is for sure space for improvement,
> we need to research through it and improve the config wrapping. So
> apologies if Agilo caused too many reload, I anyway would exclude
> completely the fact that it does this at every page call :-)
>
> Best
> ANdreaT
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to