On 5 Jun., 19:16, Lance Hendrix <la...@lancehendrix.com> wrote: > In my attempts to investigate and work on issue #7490, I decided to do > some load testing yesterday. The preliminary results of that testing > can be found on the wiki athttp://trac.edgewall.org/wiki/Performance. > Everything except the "Testing Methodology" section is accurate (I > decided to change the methodology somewhat). The current results are > only for Trac-0.11-stable and I am also planning to test > Trac-0.10-stable and the current trunk as I really want to see how much > of a (real) difference there is between 0.11 and 0.10. > > One item that surprised me was that when running the "tracd" server as > opposed to the mod_python, it appears that "tracd" is only single > threaded. That is, on my dual core test machine, it only appeared to > use about 50% or only 1/2 of both cores, as it did seem that Linux was > able to bounce the workload between the processors, but never able to > fully utilize both cores. Is this expected behavior? The actual > throughput results also bore this out in that mod_python was able to > achieve just over 80% more throughput (able to leverage both cores, > which from experience doesn't mean 100%) than tracd, obviously at a > greater memory cost (more processes/threads = greater memory consumption > and more process swapping for the kernel scheduler). > > Just wanted to be sure that I hadn't done something "hinky" to tracd > that would skew the results. Otherwise, if you get a chance, and have > an interest, let me know what you think about these results. As > indicated in my email on the user thread, I will also replicate this > testing on a server using Windows to see if that makes a difference. > > All of this was in an attempt to replicate the issue described in ticket > #7490 and as yet, I haven't been able to do so. As a matter of fact, > both tracd and trac with mod_python worked flawlessly (I was really > impressed) as I really ended up pushing them pretty hard. FYI, my final > test for mod_python (where I finally started to get some http errors > returned) required me to simulate 160 users with "0" think time. That > is, the test harness was simultaneously sending request for the three > test pages from 160 different threads (equates to about 480 simultaneous > requests), which did start to return a significant number of http > errors, but no 500 errors and no errors in the trac log (I had expected > some kind of application error, but surprisingly no)! The prior test > with 80 simulated users (240 simultaneous requests) returned absolutely > 0 (none, zip, nada) http or application errors; however, as you would > expect the response times had climbed significantly, but the Trac/Apache > were still able to service 100% of the requests, which is again > impressive! > > BTW, these loads were sustained over a 10 minute period!
do you notice some strange behaviour when running it longer? we had crashing / hanging processes when using mod_python (100% usage), but with mod_wsgi it seems to run much cleaner. os: solaris, 1.1 ghz processor. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
