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
-~----------~----~----~----~------~----~------~--~---

Reply via email to