Tracd is based on the SimpleHTTPServer that comes with Python. For the actual dynamic Trac pages, this is fine, since the bottleneck is likely it likely to be the DB anyway. Ihas no load-balancing system, so if it gets overloaded, requests will just start to time out, or worse, the server will lock up. The real problem with tracd is with static content. By default Trac serves all its static content via the /chrome handler, however this is not as efficient as a "real" web server. Really this only matters for sites that under very heavy load and are hitting performance issues. My general metric is that 25 or fewer people is absolutely fine on tracd, and 25-50 is probably okay depending on your usage patterns.
--Noah > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] > On Behalf Of Michael Schmarck > Sent: Wednesday, June 04, 2008 4:27 AM > To: Trac Users Mailinglist > Subject: [Trac] Disadvantages of tracd? > > > Hello. > > I setup Trac on a (virtual) server, which will only host Trac. Right > now, > I'm using FastCGI+lighttpd on that system and have it configured so, > that every request to / is served by the Trac FastCGI system. > > I'm currently pondering, if that makes sense to have it that way. > > Wouldn't it be easier to use the standalone tracd and have it serve > content on port 80, instead of lighttpd? Performance (speed) isn't > so important. > > What kind of disadvantages would I get, if I'd dump lighttpd (or > any other webserver, like Apache or whatnot) and would use > tracd directly? Again: That server will never host anything else > as Trac. > > Cheers, > Michael > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
