Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Trac changes, performance increase (Jeremy C. Reed)
2. Re: Trac changes, performance increase (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Tue, 3 Nov 2015 10:58:47 -0600 (CST)
From: "Jeremy C. Reed" <[email protected]>
To: [email protected]
Subject: [kea-dev] Trac changes, performance increase
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Some of the Kea community may have noticed that the Trac site was
getting slower and slower. For the Trac team it was becoming unbearable,
especially when tasks like updating tickets or generating reports were
taking over thirty seconds when should be instant.
In the trac.ini [ticket] section, I changed restrict_owner from true to
false. Great speed up. It is a known Trac issue with multiple Trac
tickets, including http://trac.edgewall.org/ticket/4245 The problem is
related to have too many user accounts and its inefficiency with
checking privileges for each. (I have no idea why it checks these
privileges for the slow HTML reports but not for the fast RSS reports.)
(Sorry I overlooked this before, as it was briefly noted also in
http://trac.edgewall.org/wiki/TracIni and
http://trac.edgewall.org/wiki/TracPerformance#Configuration.)
This means that "review to" and "reassign to" ticket actions now are
text field entry boxes and no longer a drop-down menu of username
choices. I think we can live with this until we prune out all the many
user accounts from the Kea Trac site. (Most are spammers.)
My plan is to somehow see if the Trac users have legitimate Kea wiki or
Kea ticket contributions. If not, remove the bogus user account. Once we
get the list of users down to some small amount (I guess less than 30
legitimate), we can try to renable the restrict_owner=true.
If you notice any other issues related to the "restrict_owner=false"
change, please let me know.
We have several other Trac changes to consider (like new plugins), but
we were waiting for the Trac performance to be solved first. Maybe in
two weeks we can verify this change is okay and then start with those
tasks then.
Jeremy C. Reed
ISC
------------------------------
Message: 2
Date: Wed, 4 Nov 2015 13:16:12 +0900
From: Tomek Mrugalski <[email protected]>
To: "Jeremy C. Reed" <[email protected]>, [email protected]
Subject: Re: [kea-dev] Trac changes, performance increase
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/11/15 01:58, Jeremy C. Reed wrote:
> In the trac.ini [ticket] section, I changed restrict_owner from true to
> false. Great speed up. It is a known Trac issue with multiple Trac
> tickets, including http://trac.edgewall.org/ticket/4245 The problem is
> related to have too many user accounts and its inefficiency with
> checking privileges for each. (I have no idea why it checks these
> privileges for the slow HTML reports but not for the fast RSS reports.)
Fantastic news!
On behalf on the whole team, I'd like wholeheartedly thank you for this
great feat. It was really unbearable to use trac. Finally, we can start
using this essential tool without pulling our hairs out.
> My plan is to somehow see if the Trac users have legitimate Kea wiki or
> Kea ticket contributions. If not, remove the bogus user account. Once we
> get the list of users down to some small amount (I guess less than 30
> legitimate), we can try to renable the restrict_owner=true.
There are 6339 accounts currently. I think maybe 50 of them are
legitimate, the rest is spam. I think I'm most familiar with the
accounts, so I'll go through them and will remove the spam ones.
> We have several other Trac changes to consider (like new plugins), but
> we were waiting for the Trac performance to be solved first. Maybe in
> two weeks we can verify this change is okay and then start with those
> tasks then.
Now that the performance issue is addressed, in my opinion the next step
should be to stop new spam accounts from appearing. I recall that 6 or
maybe 9 months ago we had slightly over 1000 accounts. It now grew to
over 6000. The newest accounts I saw are 15 hours old. Getting rid of
them would be pointless effort, if the new ones are being created by
spam bots.
Thank you again for solving this performance issue. Great work!
Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 1
**************************************
