IIS with Python

David Bolen db3l at fitlinxx.com
Thu Nov 29 07:23:32 CET 2001


Jim Abrams <jim at publishingresources.com> writes:

> > 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.

Yep, and that's true for any other in-proc ASP code (no matter the
language) as well - you're just loading a DLL into the IIS process.
But it's definitely higher performance and lower resource utilization.

Of course, you'd have to crash the Python interpreter which isn't all
that easy.

> > 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.

Um, that's what I think I said said (or meant to - note separate
pythonw.exe process).

In "high" the COM object invocation is via external server (or I
believe LocalServer32 in COM parlance), which is a separate process to
which COM requests are marshalled and responses demarshalled - this is
the same approach used by DCOM for remote invocation although I
believe the IPC in the former case is a low overhead RPC which in the
latter its DCE RPC.

Any ASP language is accessed as a COM object for its interpreter, and
the IIS settings are really just the standard possibilities for COM
object invocation (well, the medium involves MTS which is more an
add-on).

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

Hmm, that's interesting - I would have expected high to re-invoke an
interpreter per session.  I'm pretty sure it's invoking separate COM
object instances, but perhaps there's something in the Pythonwin ASP
support that covers that under a single interpreter?  Could you need
to restart IIS to change security models or was this a fresh page?

The definition for the Python interpreter class for LocalServer32 (the
out of process server) explicitly runs a copy of pythonw and executes
localserver.py to process the object requests, so I'm not quite sure
how you'd get away without separate pythonw processes for each
requester.

Or, I wonder if IIS (or Windows itself) is trying to be efficient and
re-use the interpreter if the pages are not accessed simultaneously
(much as a remote COM server for objects over DCOM can stay
instantiated for a period of time to avoid the overhead of
reactivating if they get reused quickly)?  I wonder if the page
accesses were simultaneous would they share the same interpreter or
not?  Or if you waited long enough before re-accessing the page would
it have retired the previous interpreter?  In that case you probably
couldn't depend on sharing the global namespace since it wouldn't be
deterministic.  I'll have to experiment when I have some time - most
of our intranet stuff right now is just run in-proc.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list