Nice job Christopher. I have no problem with combining WSGI and WSGI-SI into one handler. Also testing with my simple wsgi apps under your code and xsp2 works ok so far. Have a more complex app which I will try later tonight.

In wsgi.py you comment "There isn't an obvious way to get request protocol from HTTPRequest object". In the wsgi.py under fepy CVS that was checked in after IPCEr3 I used request.ServerVariables['SERVER_PROTOCOL'] which seems to return the correct string.

Yes performance under mono and xsp2 is not the best, I am hoping that using mod_mono may improve it but haven't had the time to set this up yet. Running under IIS seems alot faster.

Mark

On 11/2/06, Christopher Baus <[EMAIL PROTECTED]> wrote:

I spent the night hacking on the WSGI handler.  Frankly the performance I
was getting wasn't very good, and I'm making a grab at some low hanging
fruit.  Primarily the changes involves loading IronPython and the modules
once at startup (rather than per instance).

The code is a bit strange because to get the application's physical root
you have to wait until a request is handled, so the first handler does
most of the work.  I had to put some thread synchronization in there for
this reason.  I hated to do that as it creates contention on every
request, but I tried to keep the synchronization block short.

It might be worthwhile to pass the lib path in via an appSettings
parameter to avoid this contention.  The tradeoff is more configuration
for improved performance.  This could make a difference on loaded servers
(if we get that far).

I also refactored the two seperate handlers into one, which is now
configured via the appSettings in the web.config .  I also changed the way
the Python WSGI app modules are loaded.  I don't dynamically load modules
based on the path.  Instead the module is specified in the appSettings.
This is similar to how mod_python works.  I think this maps more closely
to how WSGI frameworks view themselves.  Most handle their own dispatching
and expect to be the application root.

Plus the previous method made it difficult to set the SCRIPT_NAME WSGI
environ variable correctly.  This is important for dispatching to work
correctly with most WSGI frameworks.

I am now also loading site.py (which allowed me to load in my codecs hack).

I'm looking for feedback and bug reports, and I'd like to roll this into
IPCE.  I setup a local subversion repo with anonymous checkout for my
changes here: http://svn3.cvsdude.com/baus/s2/

The performance is a bit better, but still not where I want to be.  I'll
need to look around for some other obvious problems.

Thanks,

Christopher
http://baus.net/

_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to