Python + IIS/ASP questions (modules, namespaces, etc)

dsavitsk dsavitsk at e-coli.net
Wed Dec 18 15:36:06 EST 2002


"Preston Landers" <pibble at yahoo.com> wrote in message
news:1136f745.0212180938.2827b691 at posting.google.com...
> Pythoneers:
>
> I have some technical questions about the Python ASP server side
> scripting available to IIS users.  I've seen someone post some
> questions along the same lines as the questions I have (one is quoted
> below), but unfortunately I have not seen any relevant responses.
> Perhaps I should post this on the Active Python mailing list, as that
> seems to be more win32 oriented.
>
> <snip>
>
> Currently, our Windows code works as a traditional CGI (spawning a
> python.exe for each request from IIS.)  To avoid the significant
> overhead of acquiring a new database connection for each request, the
> CGI script ends up talking (over a socket) to a limited number of
> pre-initialized "application server" processes that do the actual
> work.  This works OK for limited numbers of users, but as you might
> imagine it does not scale very well as you pile on the users.

My guess is that a single use COM server could keep track of the number of
connections and start up a new server when some threshold is reached.  I
think this is the way to do it.

> The obvious solution would be to just use Apache and mod_python on
> Windows, since we know our solution works there and we are happy with
> it.  And this may indeed be the best way to go -- I am going to look
> into the feasibility of building and packaging Win32 Apache+mod_python
> for our platform.  But, for one reason or another, the powers that be
> have indicated that we are to support IIS on Windows.

Is there any reason to not use both?  Run IIS on port 80 and Apache on 8000
and redirect traffic there when Python is involved.  If it has to be a
secret, have IIS make requests to the Apache server and and just reprint the
outcome :-)  all of the .asp pages would look like

import urllib
u = urllib.urlopen('http://my-apache-server:8000/' +
str(Request.QueryString('page')))
Response.Write(u.readlines())

Obviously this is a dumb solution, but maybe no dumber on insisting on IIS.

> <snip>
>
> The only real state I need to persist across connections is the actual
> database connection object, since these can be so expensive to obtain
> (about 3 or 4 seconds in my tests.)

That seems slow, even for win32.  On my win2k server, Python can create
literally hundreds of ADO connection objects (to an Access db!) in that much
time.

> The idea I had for that was to register a RemoteServer COM object that
> would basically act as a database connection pool.  Each web request
> would be spawned as a traditional CGI (I'm not terribly worried about
> the overhead there) -- and it would then talk to the COM object and
> send all of its database methods as packaged requests to it, and
> receive database rows (etc) in return.  All of the DB connections
> would be kept inside the RemoteServer COM object.
>
> The only drawback there (besides the work required to code up the
> database pool COM object) is that we now have to worry about correctly
> translating parameter (and exception) types across COM, which also
> uses Unicode for all strings.  Sounds like a lot of headache just to
> be able to keep a reusable database connection.

You might look to ISAPI as a way to do this.  Most notes I have seen re
Python and ISAPI have said that if you are using Python in the first place
that the performance gains you might see would be lost, so ASP is generally
an easier way to go, but in your case it may be different.  My guess is that
an ISAPI interface will require C++/Delphi/VB or some such thing though.

> Hopefully calling
> Python COM objects from Python clients should take care of most of the
> gory details, but I haven't tried it yet.

Probably not.  Python COM objects are very difficult to use as single use
COM servers. You might be better writing a Single use COM server in VB to
hold the db connection and use it from Python.  OTOH, maybe there is some
namespace stuff you could take advantage of by having the COM server import
a Python module with Global variables that will persist across all instances
(I actually think this will not work, but I am looking for someone to
explain why -- probably because each instance of a Python CO object tarts up
an instance of the interpreter).

> The most complicated
> objects we will be passing will likely be lists of tuples with varying
> simple types inside (ie, database record sets.)
>
watch out for tuples and COM ... use lists.

> Basically I'm writing this post to find out what other people may have
> done in this area and to ask for general guidance, etc.  Has anyone
> tried using ASP or a separate COM server for the sole purpose of
> database connection pooling?
>
> <snip>
>
That's my $0.02

-doug






More information about the Python-list mailing list