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.