Ryan,

My interest in the performance of Tracd, is more an academic question.  I 
understand that the maximum number will depend on a whole range of issue, 
number of users, how much work they are doing, under lying hardware, etc.

I am maintaining a Trac/Subversion system set up by the people before me.  
Subversion has been in use over 10 years and we just reach Rev 40,000.  Trac 
has been running 8 years.  There are about 20 software engineering working 
using the system.  There were some “interesting” short sited decisions may in 
the early days, that are coming back to bite us.  So I am trying to take a 
longer term view, and correct some of the earlier errors.

Currently working on a project to migrate Trac/Subversion to new hardware.  I 
would planning to use either mod_ldap or mod_sspi for the authentication, so 
this means I need Apache.  One on the issues I have been resolving the 20 
separate password files.  Basically ever system used a separate password file, 
and my users were having real problems.  We have moved to using Windows Active 
Directory as centralise authentication and Trac/Subversion are one of the last 
systems still be standalone password files.

Cheers,
David J.

From: trac-users@googlegroups.com [mailto:trac-users@googlegroups.com] On 
Behalf Of RjOllos
Sent: Saturday, 8 July 2017 4:27 PM
To: Trac Users
Subject: [Trac] Re: tracd and suggested number of users



On Friday, July 7, 2017 at 8:36:23 AM UTC-4, david.johnstone wrote:
Good Evening,

In the Trac documentation it suggestes that tracd is suitable for small 
installations and that for larger installation a “real” web server, like 
Apache, should be used.

In terms of number of users, what is a small installation?  10 users or 20 
users or 50 users.

The question is when should we switching from tracd to Apache?

Thank you,
David J.

When reviewing the documentation I've considered that statement you refer to 
might be a bit too vague because "small" and "large" depend on a number of 
factors, particularly how frequently your web users are making requests.

If you receive complaints from users or find that the latency or time to 
process a request is too great then it's possible that a web server such as 
Apache would improve performance when properly configured. Moving from SQLite 
to PostgreSQL or MySQL can also give performance improvements.

Because site performance depends on a number of factors including how your 
users are interacting with the site, you would really only be able to determine 
which changes to make by running site performance monitoring and profiling the 
request requests. Since that's a lot of work, requires expertise and is 
difficult to describe in a general way, we are left with suggesting that if 
performance isn't good enough, then you might consider switching to Apache or 
changing the database backend. I suggest setting up a mirror of your site and 
making incremental changes while profiling the requests using browser tools 
until you get the performance improvements you are looking for.

More information here:
https://trac.edgewall.org/wiki/TracPerformance

Are you running into any performance issues?

- Ryan
--
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
trac-users+unsubscr...@googlegroups.com<mailto:trac-users+unsubscr...@googlegroups.com>.
To post to this group, send email to 
trac-users@googlegroups.com<mailto:trac-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to