Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)

2006-11-10 Thread Jorey Bump

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)

2006-11-09 Thread Graham Dumpleton
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)

2006-11-09 Thread Jorey Bump

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)

2006-11-09 Thread Jim Gallacher

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)

2006-11-09 Thread Graham Dumpleton
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