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.
<br><br>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.
<br><br>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.<br><br>Mark<br><pre><br></pre><div>
<span class="gmail_quote">On 11/2/06, <b class="gmail_sendername">Christopher Baus</b> <<a href="mailto:christopher@baus.net">christopher@baus.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>I spent the night hacking on the WSGI handler. Frankly the performance I<br>was getting wasn't very good, and I'm making a grab at some low hanging<br>fruit. Primarily the changes involves loading IronPython and the modules
<br>once at startup (rather than per instance).<br><br>The code is a bit strange because to get the application's physical root<br>you have to wait until a request is handled, so the first handler does<br>most of the work. I had to put some thread synchronization in there for
<br>this reason. I hated to do that as it creates contention on every<br>request, but I tried to keep the synchronization block short.<br><br>It might be worthwhile to pass the lib path in via an appSettings<br>parameter to avoid this contention. The tradeoff is more configuration
<br>for improved performance. This could make a difference on loaded servers<br>(if we get that far).<br><br>I also refactored the two seperate handlers into one, which is now<br>configured via the appSettings in the web.config
. I also changed the way<br>the Python WSGI app modules are loaded. I don't dynamically load modules<br>based on the path. Instead the module is specified in the appSettings.<br>This is similar to how mod_python works. I think this maps more closely
<br>to how WSGI frameworks view themselves. Most handle their own dispatching<br>and expect to be the application root.<br><br>Plus the previous method made it difficult to set the SCRIPT_NAME WSGI<br>environ variable correctly. This is important for dispatching to work
<br>correctly with most WSGI frameworks.<br><br>I am now also loading site.py (which allowed me to load in my codecs hack).<br><br>I'm looking for feedback and bug reports, and I'd like to roll this into<br>IPCE. I setup a local subversion repo with anonymous checkout for my
<br>changes here: <a href="http://svn3.cvsdude.com/baus/s2/">http://svn3.cvsdude.com/baus/s2/</a><br><br>The performance is a bit better, but still not where I want to be. I'll<br>need to look around for some other obvious problems.
<br><br>Thanks,<br><br>Christopher<br><a href="http://baus.net/">http://baus.net/</a><br><br>_______________________________________________<br>users mailing list<br><a href="mailto:users@lists.ironpython.com">users@lists.ironpython.com
</a><br><a href="http://lists.ironpython.com/listinfo.cgi/users-ironpython.com">http://lists.ironpython.com/listinfo.cgi/users-ironpython.com</a><br></blockquote></div><br>