IIS with Python

[Jim Abrams]

David Bolen <db3l at fitlinxx.com> wrote in 
news:un118q3g9.fsf at ctwd0143.fitlinxx.com:

> tub4jxr at hotmail.com (Jose Rodriguez) writes:
> 
>> I have looked at the Python.org site but I must admit that I am a
>> little unsure of whether a separate python interpreter is started on
>> each call from a different IIS session that needs to run some Python
>> code. 
> 
> Assuming you are referring to using Python for ASP pages in IIS (and
> not via a CGI setup which would I believe be forced to use separate
> processes per connection), I think it depends on how you define the
> scripting support for that page in IIS, just as with other scripting
> languages.
> 
> The Python ASP support is implemented via the COM interface registered
> by Pythonwin (the win32all package).  So the invocation of the
> scripting environment depends on how the COM object is instantiated.
> 
> In IIS you can set the scripting support for a page to use one of
> three levels of application protection: Low (IIS process), Medium
> (pooled) and High (Isolated).  They directly correlate to how the COM
> object for the scripting host is invoked.
> 
> In low (IIS process), the scripting interpreter is loaded as an inproc
> server (via the pythoncom##.dll file), and while I'm not sure if a
> separate interpreter is created internally for each user, you won't
> have individual processes running on your IIS box - just the one DLL
> loaded straight into your IIS process.

This means that your python code runs inproc with the IIS proc. Don't do 
anything too drastic or you can crash the IIS proc too.


> In High, a completely separate COM object is instantiated (via
> execution of a separate pythonw.exe process running a localserver
> script) and you will have a completely separate process for each
> connection to the server.

I don't think this is how it works. IIRC, the isolation means that the 
application is running in its own process, meaning that IIS must use IPC to 
talk to the intepreter and when the interpreter proc crashes or does 
something extermely bad, IIS doesn't go with it. This also makes it nice 
for debugging and reloading your Python ASP pages, Python COM servers and 
elsestuff. You do lose a little performance this way.

> In Medium, a pool of separate COM objects is maintained (I think via
> MTS but am not positive), so you'll have separate processes, but not
> as many as clients, but several shared among clients.

Still just 1 interpreter for the whole site.

Here's a simple example, I have it set to High (Isolated)

<%@LANGUAGE="Python"%>
<%
from win32com.axscript.client.framework import SafeOutput
_out = SafeOutput(Response)

import sys

if hasattr(sys, 'some_dict'):
	sys.some_dict[Session.SessionID] = ''
else:
	sys.some_dict = {Session.SessionID: ''}
	

print >> _out, "<br>test", sys.some_dict
print >> _out, "<br>ID", Session.SessionID
%>


And 4 separate browsers:

Browser 1:
test {u'703945915': ''} 
ID 703945915 


Browser 2:
test {u'703945915': '', u'703945916': ''} 
ID 703945916 


Browser 3:
test {u'703945915': '', u'703945916': '', u'703945917': ''} 
ID 703945917 


Browser 4:
test {u'703945915': '', u'703945916': '', u'703945917': '', u'703945918': 
''} 
ID 703945918 


As you can see they are sharing not just the interpreter, but modules as 
well, I suppose that means the global namespace is shared? This makes for 
all kinds of fun, such as using a module as an application level cache 
(works faster than Application), or rewriting your own Session object and 
other fun stuff.