Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)
Jorey Bump wrote: But going back to 3.2.10 hasn't restored the performance I was seeing earlier, so this may be a nonissue. I'll report back if there are any changes. I tried a few more tests, cycling between versions. 3.2.10 still seems to be a little faster, but I've been able to reach similar numbers with 3.3, just less often. This is consistent with Graham's expectations, so I wouldn't be overly concerned. I agree completely with Jim: "Make it work right, then make it work fast." I'm much more interested in the improvements available in 3.3.
Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)
Jorey Bump wrote .. > Graham Dumpleton wrote: > > > There are two things you can do to gauge where any loss arises. First > is to > > ensure that module reloading is turned off and see how that changes things. > > > > PythonAutoReload Off > > > > The second is to reenable the old module importer as a comparison. This > needs > > to be done at global scope within main Apache configuration: > > > > PythonOption mod_python.legacy.importer * > > > > The argument is actually a comma separated list of interpreter names > for which > > to use the old importer. Listing just '*' has the effect of using the > old importer > > for all interpreter instances. > > I'm getting the same results with either or both options, so it may be > a > simple system glitch or a performance hit elsewhere. There are other places besides the new module importer where changes were made which affect all requests, regardless of which importer is used. I started mentioning these in my past mailed but then dropped it as I couldn't see that they would be that significant as they fall within the C code component. Most of the changes should also only have an impact where stacked handlers are used, or where wildcards or regexps are used with Directory directive. That or where specific features are used from user code, but in the main these are features which I don't think can be used in older versions anyway. The only other area I have been concerned about is how we have been progressively adding to the chain of strcmps in request object where special stuff has to be done when accessing or setting attributes. This would only be an issue though if user code did lots of request object attribute lookups which fall into the set where the serial strcmps are done. Cleaning up request object was one of the things on my mental list for next version. If you manage to identify a particular area as being a problem, do let me know. In the mean time I'll have a bit of a check back over the code and have a think about what other changes could have been made that might have a significant effect. Will also see if I can get any sort of consistent results out of my PowerBook and compare older mod_python with new. Graham
Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)
Graham Dumpleton wrote: There are two things you can do to gauge where any loss arises. First is to ensure that module reloading is turned off and see how that changes things. PythonAutoReload Off The second is to reenable the old module importer as a comparison. This needs to be done at global scope within main Apache configuration: PythonOption mod_python.legacy.importer * The argument is actually a comma separated list of interpreter names for which to use the old importer. Listing just '*' has the effect of using the old importer for all interpreter instances. I'm getting the same results with either or both options, so it may be a simple system glitch or a performance hit elsewhere.
Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)
Graham Dumpleton wrote: Jorey Bump wrote .. I've installed it on a lightly used production server so I can test it against some real-world apps. Initial testing indicates that it's 10-20% slower than 3.2.10; I'm not sure why. Can I turn on the legacy importer with a runtime configuration, or do I need to recompile? I'd like to compare the two. Expected it would be slower for a few reasons. I don't have a good system on which to do any comparative tests, so was never sure how much performance hit there would be. I did state though early on that the initial aim would be to get it working properly and then we can look at the performance and tweak it so as to regain as much as possible of what was lost. And there was no argument there. Make it work right, then make it work fast. :) At some point we should create some sort of a performance tuning page. I was thinking of this the other day wrt the number of mutex locks, but at this point we haven't done any benchmarking so the advice is... more is better... probably. :) Jim
Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)
Jorey Bump wrote .. > I've installed it on a lightly used production server so I can test it > against some real-world apps. Initial testing indicates that it's 10-20% > slower than 3.2.10; I'm not sure why. > > Can I turn on the legacy importer with a runtime configuration, or do I > need to recompile? I'd like to compare the two. Expected it would be slower for a few reasons. I don't have a good system on which to do any comparative tests, so was never sure how much performance hit there would be. I did state though early on that the initial aim would be to get it working properly and then we can look at the performance and tweak it so as to regain as much as possible of what was lost. The main culprit will be the new module importer. This is primarily going to be due to it doing extra checks on whether module files or other modules they have imported, have been modified. I would expect that this would be the bulk of any performance loss especially since done in Python code. There are two things you can do to gauge where any loss arises. First is to ensure that module reloading is turned off and see how that changes things. PythonAutoReload Off The second is to reenable the old module importer as a comparison. This needs to be done at global scope within main Apache configuration: PythonOption mod_python.legacy.importer * The argument is actually a comma separated list of interpreter names for which to use the old importer. Listing just '*' has the effect of using the old importer for all interpreter instances. Graham