Am Donnerstag, 12. März 2015 17:24:27 UTC+1 schrieb tol...@gmail.com:
> Does that affect the results that are stored in trac's database though?
If I wanted to look at the build results from revision 5000 and now I'm on
revision 1, but set the "First revision" to 9800, wouldn't everything
b
On Wed, Mar 11, 2015 at 12:54 PM, Tom Luiz wrote:
> Specifically, what does "memcache hit" or "dbcache hit" mean?
>
> Thanks
>
It looks like DirectoryAuthPlugin, which you appear to be using to
authenticate against your ActiveDirectory or Ldap store, implements a cache
to avoid database hits whe
That does indeed sound like a good idea.
Does that affect the results that are stored in trac's database though? If
I wanted to look at the build results from revision 5000 and now I'm on
revision 1, but set the "First revision" to 9800, wouldn't everything
before 9800 be deleted?
Maybe t
Specifically, what does "memcache hit" or "dbcache hit" mean?
Thanks
On Wed, Mar 11, 2015 at 12:27 PM, wrote:
> Ok. Here is the debug log output for three pages that took ~10 seconds to
> load each. This is on the faster side of loading times. As you can see,
> trac has to restart itself ever
Hi,
Am Mittwoch, 11. März 2015 18:56:28 UTC+1 schrieb Tom Luiz:
>
>
> Any idea why Bitten is slowing things down a lot? I know we have a patch
> that was applied to add some desired functionality to Bitten, like
> keep-alive communication, network timeout retries, etc.
>
I also use Bitten and k
On 03/11/2015 04:24 PM, Steffen Hoffmann wrote:
Hm, I'm running past 10k tickets with a lot more than 5 users on SQLite
by now, and this is not even latest Trac stable but plugins mostly still
using the depreciated Trac 0.11 db API.
I think *concurrent* user requests are the issue, not total num
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.03.2015 18:30, tolu...@gmail.com wrote:
>> On 03/11/2015 01:24 AM, tol...@gmail.com wrote:
>> - There are about 1000 tickets, and about 50 users.
>
> Eeep... we couldn't get past 5 users on SQLite. SQLite has very coarse
> locking, so it would l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.03.2015 20:27, tolu...@gmail.com wrote:
> Ok. Here is the debug log output for three pages that took ~10
> seconds to load each. This is on the faster side of loading times.
> As you can see, trac has to restart itself everytime it loads a
> new
Ok. Here is the debug log output for three pages that took ~10 seconds to
load each. This is on the faster side of loading times. As you can see,
trac has to restart itself everytime it loads a new page.
The three pages that I navigated to are, /reports, /admin, and
/wiki/test_Tomas - a sandbox
On Wed, Mar 11, 2015 at 10:56 AM, wrote:
> Ok, I think the plugin was installed when my predecessor tried to perform
> the migration. I can try to go through it again.
>
> Any idea why Bitten is slowing things down a lot? I know we have a patch
> that was applied to add some desired functionality
Ok, I think the plugin was installed when my predecessor tried to perform
the migration. I can try to go through it again.
Any idea why Bitten is slowing things down a lot? I know we have a patch
that was applied to add some desired functionality to Bitten, like
keep-alive communication, networ
On Wed, Mar 11, 2015 at 10:30 AM, wrote:
> I'm strongly considering switching to PostgreSQL. Is it a straightforward
> transition?
> Can you point me to a link or describe how you performed the switch?
>
> A lot of my users are not here anymore. Would it help to delete their user
> accounts?
> Wo
I'm strongly considering switching to PostgreSQL. Is it a straightforward
transition?
Can you point me to a link or describe how you performed the switch?
A lot of my users are not here anymore. Would it help to delete their user
accounts?
Would that affect any tickets they're associated with?
On 03/11/2015 01:24 AM, tolu...@gmail.com wrote:
- I am running an Apache2 web server. I believe the site is running as a
fast cgi script. Does that also hamper performance?
Yes. I suggest using WSGI. http://trac.edgewall.org/wiki/TracModWSGI
- There are about 1000 tickets, and about 50 user
Hi Tom,
I can confirm similar issue - loading wiki page time is around 30sec on 1.1
Trac.
Hosting company is blaming cgi scripts for this delay but, as I learned
from you thread, it could be issue with bitten.
Thanks
K.
On 11 March 2015 at 05:24, wrote:
> Sound like great suggestions!
>
> -
Sound like great suggestions!
- It's possible the performance issues started when I upgrade to 1.0. I
don't remember it being that slow at that time though. I was running 0.12 I
believe.
- I am running on Ubuntu.
- I am running an Apache2 web server. I believe the site is running as a
fast cgi
On Tue, Mar 10, 2015 at 4:09 PM, wrote:
> Hi,
>
> Thanks for the response! I thought that I was being blocked so I didn't
> check in until now.
>
> I am running SQLite, indeed. I upgraded to Trac 1.0 back in November.
>
There are a lot of possibilities so I'm going to start with some basic
quest
Hi,
Thanks for the response! I thought that I was being blocked so I didn't
check in until now.
I am running SQLite, indeed. I upgraded to Trac 1.0 back in November.
The biggest problems that I have are that:
1. It takes Trac ~30 seconds to load a wiki page.
2. My predecessor had the SV
On Thu, Feb 26, 2015 at 9:46 AM, wrote:
> Hello,
>
> My name is Tom and my development team has had trac set up with bitten and
> a mysql lite
>
You are either running SQLite or MySQL, so that would be a good point to
clarify, though I assume that's just a typo and you mean SQLite.
> database
Hello,
My name is Tom and my development team has had trac set up with bitten and
a mysql lite database for the last four years. Unfortunately, the most trac
knowledgeable colleagues have since left, and having taken over the
responsibilities, I have a lot of questions to ask as well as problem
20 matches
Mail list logo
