[IronPython] Rewrite of WSGI handler

[Mark Rees]

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 <christopher at baus.net> 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
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20061102/061214c7/attachment.html>