FYI, Chris is out this week. I'm sure he'll reply back when he returns next week.
Doug Hughes, President Alagad Inc. [email protected] 888 Alagad4 (x300) Office: 919-550-0755 Fax: 888-248-7836 On Fri, Jun 5, 2009 at 12:57 PM, Lance Hendrix <[email protected]>wrote: > > I did some load testing yesterday with almost this same configuration > and I was able to achieve some pretty good results and did not see any > issues. I am not yet prepared to publish the results, but one > interesting difference was that you appear to be running this on > windows, whereas I was running on Linux. > > Just as an FYI, I was able to get just over 18 requests/second with > about an average of 1s for page load with tracd and was able to get just > over 34 requests/second with mod_python with sub second page load times > on an AMD dual core 2mhz. The testing results page I am putting > together has much more detail on the hardware and software configuration > I was using as I know these numbers probably don't mean too much without > that detail, but thought you might find them re-assuring (that it is > possible). > > I will replicate the test on Windows and see if I can reproduce this > issue. Once I have finished polishing the results and working with the > devs to ensure they are reasonable, I will happily publish the details > of this testing. > > The reason for my doing this is that I am attempting to assist with > ticket #7490 (http://trac.edgewall.org/ticket/7490) but I have not yet > been able to reproduce the issue. However, I have not had as much > detail (as yet) as you have provided, so this information is much > appreciated. > > Chris Peterson wrote: > > I work with Doug on this issue, and I wanted to provide some > > additional details about our configuration and what I am seeing. > > > > The server is an Amazon EC2 small instance, running on a dual core > > Opteron 2.6 ghz w/ 1.66 gig of ram > > The Trac install lives in the default c:\python25 folder, and the > > trac / svn data lives on an S3 drive. > > > > We have 49 trac environments running here, 4 of which have their own v- > > host configured, the rest are for internal use and share a root url. > > All of these environments also have SVN setup. The majority of the > > shared instances have a common configuration base trac.ini file, with > > individual files for environment specific configurations. > > > > I started out with the 0.11 install of Trac, and have since upgraded > > to the 0.12dev-r8263 release from SVN (using easy_install and pointing > > to the SVN repo location), to try and address our performance issues. > > Under 'About Trac', here is my current config: > > > > Trac: 0.12dev-r8263 > > Python: 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC > v.1310 > > 32 bit (Intel)] > > setuptools: 0.6c9 > > SQLite: 3.5.2 > > pysqlite: 2.4.0 > > Genshi: 0.6dev-r1052 > > Babel: - > > mod_python: 3.3.1 > > Pygments: 1.0 > > Subversion: 1.5.4 (r33841) > > jQuery: 1.1.3.1 > > > > I have Apache connecting using mod_python, but this slow performance > > and 100% CPU peak usage persists even if I load a single environment > > using tracd and shut-down the apache instance. I have gone through the > > site-packages and, one by one, removed each plugin from the folder and > > re-started the instance, and I still saw the performance issues (I was > > trying to isolate the issue to a single plugin, without luck). > > > > I applied the patch as suggested in > http://trac.edgewall.org/ticket/7785#comment:13 > > and have seen no improvement. I also have logging currently disabled > > completely in the hopes of improving performance, still without luck. > > > > I did a directory output from my site-packages folder, if it will > > provide better detail as to plugins I have installed, that you can > > view here: http://pastebin.com/fea11695 > > > > The worst performance seems to be on the wiki pages, but viewing > > tickets spins the CPU up quite high as well. At one point I attempted > > to implement the Psyco package (http://psyco.sourceforge.net/) to > > improve performance, but all plugins have been updated without it > > again as I saw no performance gains from using it (the package is > > still in my site-packages, but the code is not in use) > > > > At this point I am (sadly) thinking that I may need to re-configure a > > new server with a clean / new install of python and trac and see how > > it runs, I really do not know what else to investigate to resolve this > > problem. Any idea's, as wild as they may be, would be greatly > > appreciated! > > > > Chris Peterson > > > > > > On Jun 4, 6:31 pm, Christian Boos <[email protected]> wrote: > > > >> Doug Hughes wrote: > >> > >>> Hi, > >>> > >>> We have a new install of Trac running on Windows with Apache. > >>> (Generally, the same setup as our old Trac instance.) Unfortunately, > >>> performance is terrible. Requests spike the box to 99% cpu and httpd > >>> is taking 500mb. We're out of ideas here and I'd like to have someone > >>> come in, take a look at our config, tell us what we did wrong, and > >>> then make it work. > >>> > >> This sounds a lot like ticket #7490. > >> Please give us more details about your installation > >> (http://trac.edgewall.org/wiki/NewTicketGuidelines#HowtoProceed). > >> > >> You may try 2 different things: > >> - reduce the log_level if it's set to DEBUG, down to ERROR > >> - apply the patch on #7785 > >> (http://trac.edgewall.org/ticket/7785#comment:13) > >> > >> -- Christian > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
