Mailing List Archive: Trac: Users

Just how flexible is trac?

Index | Next | Previous | View Threaded

yoursurrogategod at gmail

Apr 12, 2012, 7:01 AM

Post #1 of 4 (335 views)
Permalink

Just how flexible is trac?

Hi all,

My company currently uses an antiquated bug-tracking system. It
sucks. Written in classic ASP, it's slow, runs only in Internet
Explorer and is a joke at this point (it might have not sucked at one
point, but at this late stage of the game it's a Yugo). However, one
of the requirements that we have is that thousands of people should be
able to use this (there is a large number of people in the company).
What I would like to know is how well would Trac handle so much
traffic?

- Have you had instances where you were working for a large
organization where there were many individuals who were using Trac to
not just keep track of software bugs, but other changes (requests for
permissions to directories, password resets, etc.)
- How well did this work?
- Were there any drawbacks?

Would greatly appreciate some feedback on this!

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

sgifford at suspectclass

Apr 14, 2012, 7:21 PM

Post #2 of 4 (317 views)
Permalink

Re: Just how flexible is trac? [In reply to]

On Thu, Apr 12, 2012 at 10:01 AM, Yves S. Garret <yoursurrogategod [at] gmail
> wrote:
[ ... ]
>
> one
> of the requirements that we have is that thousands of people should be
> able to use this (there is a large number of people in the company).
> What I would like to know is how well would Trac handle so much
> traffic?
>

I haven't done this personally, but since nobody else has weighed in, maybe
this will be helpful. Performance will probably depend a lot on server
hardware, etc. Various bits of documentation indicate that it will scale
much better using Postgres. Here are a few links that might be useful:

- Trac Load Testing with
JMeter<http://trac.edgewall.org/wiki/TracPerformance/LoadTestingWithJmeter>
- Trac and Performance <http://trac.edgewall.org/wiki/TracPerformance>
- Trac Database Backend <http://trac.edgewall.org/wiki/DatabaseBackend>

If you do some measurements, I'm sure the list would be very interested to
see them.

Good luck!

------Scott.

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

kureikain at gmail

Apr 14, 2012, 8:42 PM

Post #3 of 4 (323 views)
Permalink

Re: Just how flexible is trac? [In reply to]

I have an server jus 512MB RAM. I can tell you, performance is really great
and very flexible.
You can add anything you want. Just search on track hack.

Notification. Git Intergarion,...
Thing goes smoothly with Trac.

On 14 April 2012 19:21, Scott Gifford <sgifford [at] suspectclass> wrote:

> On Thu, Apr 12, 2012 at 10:01 AM, Yves S. Garret <
> yoursurrogategod [at] gmail> wrote:
> [ ... ]
>
>> one
>> of the requirements that we have is that thousands of people should be
>> able to use this (there is a large number of people in the company).
>> What I would like to know is how well would Trac handle so much
>> traffic?
>>
>
> I haven't done this personally, but since nobody else has weighed in,
> maybe this will be helpful. Performance will probably depend a lot on
> server hardware, etc. Various bits of documentation indicate that it will
> scale much better using Postgres. Here are a few links that might be
> useful:
>
> - Trac Load Testing with JMeter<http://trac.edgewall.org/wiki/TracPerformance/LoadTestingWithJmeter>
> - Trac and Performance <http://trac.edgewall.org/wiki/TracPerformance>
> - Trac Database Backend <http://trac.edgewall.org/wiki/DatabaseBackend>
>
> If you do some measurements, I'm sure the list would be very interested to
> see them.
>
> Good luck!
>
> ------Scott.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" group.
> To post to this group, send email to trac-users [at] googlegroups
> To unsubscribe from this group, send email to
> trac-users+unsubscribe [at] googlegroups
> For more options, visit this group at
> http://groups.google.com/group/trac-users?hl=en.
>

--
Kurei

Website: http://axcoto.com
Shop: http://codecanyon.net/user/kureikain/portfolio

<http://axcoto.com/>

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

mjh-lists-trac-users at liminalflux

Apr 24, 2012, 1:12 PM

Post #4 of 4 (277 views)
Permalink

Re: Just how flexible is trac? [In reply to]

> On 14 April 2012 19:21, Scott Gifford <sgifford [at] suspectclass
> <mailto:sgifford [at] suspectclass>> wrote:
>
> On Thu, Apr 12, 2012 at 10:01 AM, Yves S. Garret
> <yoursurrogategod [at] gmail <mailto:yoursurrogategod [at] gmail>> wrote:
> [ ... ]
>
> one
> of the requirements that we have is that thousands of people
> should be
> able to use this (there is a large number of people in the company).
> What I would like to know is how well would Trac handle so much
> traffic?
>
>
> I haven't done this personally, but since nobody else has weighed
> in, maybe this will be helpful. Performance will probably depend a
> lot on server hardware, etc. Various bits of documentation indicate
> that it will scale much better using Postgres. Here are a few links
> that might be useful:

> If you do some measurements, I'm sure the list would be very
> interested to see them.

Postgres definitely helps. At $work we switched from sqlite to postgres
recently, and upgraded the hardware, because we were hitting the db
locked issue too often and it was starting to take 10-20s to load a page.

I wouldn't set up a trac instance with 1000s of users without postgres
and enough memory to run lots of apache children.

Our current setup is:

* around 50 active users
* 200,000 svn revisions
* 38,000+ tickets
* bitten plugin

running on a dual-core 2Ghz Xeon, 12 Gb memory, 1Tb drive
(The same box is also running a couple of other services).

Trac db is at 1Gb, with 27Gb of attachments.

I'm curious as to what other people's stats are.

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-users [at] googlegroups
To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads