Lance Hendrix wrote: > Thank you for the quick and elaborate response! I wanted to follow up > on this great email with a status of where I am and express my > appreciation for your direction. I have edited out a bit of this in > order to shorten the email so that it isn't too long... > > My initial efforts have been to get a development environment up and > running (I have done several user installations, but obviously never > setup a "trac development environment). I initially started out > attempting to do this on Windows (Vista x64 to be exact), but ran into > some issues
Well, Vista x64 is also my main development platform, although I mostly use the 32-bits version of Python those days (I didn't have any issues with the 64-bits version, it's just that you find less pre-built 64-bits Python packages on the net). > Christian Boos wrote: > >> Hello Lance, >> >> >> Starting to work on the 0.11.x bug reports is where the contributions >> will be the most immediately useful. >> I think 0.11.5 is mostly ready to go, though among the opened tickets, >> there are still a few outstanding ones that would be better fixed in >> 0.11.5 rather than later (e.g. #7490, #4245). In general, pick any >> ticket in 0.11.5 or 0.11.6 that match your center of interest, and go >> for it: verify that an issue is reproducible, test an already proposed >> fix, review existing patches, and of course, propose your own fixes. By >> commenting on the tickets, you'll usually get feedback from the other >> developers pretty quickly. >> >> > I am currently looking into #7490 which is very interesting and also > in-line with some of my professional experience which has focused on > performance and scalability of platforms and applications. In my > preliminary review and attempt to understand the issue as it relates to > #7490, I have found a couple of things that I wanted to get feedback on > (let me know if this is better placed into the comments of the issue, > but it is quite deep into the code and most of the discussion on the > ticket is at a "higher" level)... > > * The a major change from Trac-10 to Trac-11 was leveraging Genshi > * One of the initial issues reported and resolved was ticket #6614 - > Memory leak using Apache (I am still sorting through the details of this > ticket) > * In reviewing the code, one of the changes related to ticket #6614 was > to explicitly force a garbage collection at the end of request processing > Correct. And #6614 is for sure an interesting read ;-) Part of that journey, a few bugs in Python itself have been uncovered. I still think there's something fishy in the way gc works in Python: you can try to comment out the explicit gc at the end of each request, but then you'll see the memory usage skyrocket (unless the behavior has changed since the last time I tried). > My current thinking is that the explicit garbage collection (which is > synchronous with the user request) is what is causing the (at least > perceived) performance problem (whether this is related to Genshi or not > is still unknown based on my preliminary testing). I have not been able > to reproduce the problem as yet, but I also have a few suspicions as to > why and am currently svnsync(ing) a repo that has more history and data > to see if that allows me to better repro the problem. Once I can repro > then I am sure we can fix... > > * I also assume that part of the issue why this hasn't been addressed > is that we still don't know exactly why/how this occurs? > Yes. > * Has anyone been able to repro the issue in a development environment? > Perhaps... see below. > * Is anyone else actively working on this issue (that I should be > collaborating with)? > That would be me, AFAIK, although I've not yet digged too deeply. Feel free to approach the problem from your angle (as there are certainly multiple factors at play, that would be a good thing anyway). > * What do we know (or don't) know that might not be in the ticket > discussion? > In #7490, some comments (like http://trac.edgewall.org/ticket/7490#comment:12, comment:38, comment:45) about Apache or fcgi spiking at 100% might actually be the #7785 issue. comment:13 and 15 suggests that turning KeepAlive off improved things a lot. Maybe the HTTP 1.1 related fixes I did since for #8020 (setting the Content-Length everywhere) are now helping in this situation. OTOH, he was using mod_python 2.4.5, which is old and possibly buggy in this respect. comment:22 was actually #8067 (a problem when using the inappropriate MyISAM table engine in MySQL, so a repository resync was done prior to each request - see comment:36). http://trac.edgewall.org/ticket/7490#comment:57 and comment:60 are really interesting: they show that the log level could be involved. Indeed, at log_level = DEBUG, we write quite a lot of data. But that alone shouldn't be problematic. When working with tracd, I witnessed a few times a strange effect with the logging: every log output was duplicated. This actually happened quite seldom and I've not yet found a way to trigger this behavior (hence the "perhaps..." above). This suggests that there's some sort of race condition when we're updating the log handler for an environment (see trac/log.py and trac/env.py, Environment.shutdown - see also #3833 for background) and we end up with more than one handler for an environment. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
