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

[Preston Landers]

"dsavitsk" <dsavitsk at e-coli.net> wrote in message news:<W_4M9.2152$qU5.1302847 at newssrv26.news.prodigy.com>...

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

This is actually not a bad idea -- however it is complicated by some
details that I did not mention in my original posting.

We had already thought of a solution like this, but we have inherited
a fairly broken design for a caching layer in these application
servers.

Basically, each app server maintains a socket connection to *every
other* app server for the sole purpose of sending brief "clear caches
for table X" messages to each other.  That means the total number of
interconnections required grows exponentially as the number of app
servers increases linearly.  Yeah, I know, it's ridiculous.

We discussed ripping that design out and basically making a
centralized cache process, so that each app server only has to talk to
1 process (though there might be a backup process or two.)  

When we discussed that, we basically ruled it out for the time being
due to the complexity involved in the redesign of the caching logic.
However, the more I look at our options here, the more I see that this
appears to be really the least complicated solution in some respects.

If we went that route, we could probably cut out the CGI script
overhead (spawning python.exe) and just have a snippet of ASP-safe
code directly contact an app server.


> > 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 :-)  
<snip>
> Obviously this is a dumb solution, but maybe no dumber on insisting on IIS.

Right -- we could use Apache anyway, and have a passthrough from IIS.
I'm sure there's a faster way to do the passthrough than with Python.
I'm fairly confident that if we can demonstrate a stable, widely
usable mod_python/win32 build, then we will be able to use it (no
secrecy required ;-))

I am going to be spending some time in the near future trying to get a
build of mod_python for win32.


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


We're talking about ODBC connections to MS Sql Server and/or Oracle
here.  The slowdowns appear to be in either ODBC itself or the
Python/ODBC layer (which has given us a number of headaches and
stability problems in general ...)  We're using the odbc.pyd module
that
comes with Python 2.1.1.


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

We've also considered an ISAPI dll -- and decided that we did not have
the expertise (or the budget) to do a proper job of this in-house.
Ultimately, this would probably provide the fastest performance with
the most flexibility, but would require lots of up-front development
(plus tie us to IIS even more than we are.)


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

That's a little scary.  Any particular reason why?  

I suppose we can just pass the list around and then do a "rec =
tuple(rec)" thing when we get the recordset back (because our code is
expecting tuples in some cases.)

thanks for the input!

yours,
Preston Landers