Good points all and I do agree that some sort of testing harness/framework/setup that reduced dependencies (or that was at least OSS and easily available) would be preferred. My only reason for using the tools I chose were that they were "close at hand" and I was familiar with them; however, I will take suggestions...
If we can't find something else then wget and some scripting may suffice, but I am somewhat skeptical of their results as compared to an actual "load testing tool" as I don't know if they can take into consideration a number of factors that IMHO are important for load testing (specific measurements like TTFB (time to first byte) more commonly known as response time and TTLB (time to last byte) often known as page load time as well as the ability to simulate various loading characteristics like simulated number of users, etc). But then again, perhaps we could have something basic for people to do a simple baseline of their installation with wget and some scripting and a more detailed testing configuration for others. Let me know if you have any ideas, objections, suggestions, criticism, or general gripes... ;-) I also agree that the scope of the testing configuration needs to be broadened and as I find suggestions like yours below (postgres), I will work to incorporate them into my test plans (testing various backend configurations could provide people with some interesting insights)... Also, I don't recall or haven't yet found any information regarding recommended configurations (may be a can of worms you don't want opened) or at least some information regarding the various trade offs of the various configuration options (tracd vs. mod_python vs. wsgi and mysql vs. sqlite vs. postgres). I do seem to recall some information in the various administration/install documentation, but I don't know if it would be valuable to have something that is more focused on this topic? I don't know if (all/any of) this is or is not in the spirit of the project (still working to get my bearings with everyone and the project), so if this has been discussed and decided in the past or if it is not in the "spirit" of the project, please provide guidance/correction as necessary to help get/keep me on track. Also, if the project does not find or doesn't think this is valuable and you think there are other areas of higher priority that I could apply my time and efforts to, I would welcome that feedback as well... :-) Lance Greg Troxel wrote: > I am not surprised that tracd seems single threaded. Does anyone expect > it to run multiple threads? > > It would be really nice to have a standard test harness, something that > assumed only POSIX sh and wget, for example. I am also wondering about > performance of my box so may get to that. I would want the test harness > to support user credentials (basic or digest auth) and ssl. > > Besides mod_python, I think it's interesting to look at mod_wsgi. Then > there's the prefork mpm vs the worker mpm, but I'm not sure things are > thread-safe enough for the worker mpm. > > I have had problems with mod_python with memory leaks into the master > httpd process. I am running on xen domUs (NetBSD/i386 4.0ish) which > tend to be low memory and have 256m datasize limits. Those are fine > until there are leaks. With recent mod_wsgi I haven't had these > problems. But, I've also been doing daily restarts of apache in the wee > hours to avoid problems from leaks given the large number of users. > > I am using postgresql for the database - another variable in the mix. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
