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

[Preston Landers]

"dsavitsk" <dsavitsk at e-coli.net> wrote in message news:<U2bM9.2221$qU5.1353476 at newssrv26.news.prodigy.com>...

> I am not sure I understand this at all, but it sounds like you have created
> a workgroup with a hub when what you want is a hub and spoke server
> client/system with a switch.  very odd.

I suppose that is one way to look at it.  Yes, the design that I
inherited is very odd.  I'm not exactly fond of it.  I do believe that
we may focus turning it into a "hub/spoke" model.

> 
> > 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.)
> 
> With a couple of processors and a well written threaded COM server (or maybe
> something along the lines of how Medusa is designed to avoid threads) this
> seems like a reasonable idea.

Rather than using COM (since we would probably want to use the design
on Unix as well) I was thinking just a simple select() based process
that served as a clearinghouse for the 'clear cache' and other such
messages.  When and if we determined that it was a bottleneck we could
rewrite it in C.

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

Yeah, it's absurdly slow.  It's slow when creating the very first
connection in the life of the process, but subsequent connections are
fairly fast.  However, for our purposes (CGI) each request will
essentially be a new process, so we still have the delay.

Just now I did a few simple tests playing around with ADO.  It does
look like ADO is definitely the way to go here.

On my test system (PIII 600 mhz w/ Windows XP + SQL Server 2000) -- it
takes usually around 2.2 seconds on average to create the first ODBC
based connection.  However, the same ADO connection only takes about
0.12 seconds the first time (and less subsequently.)

So, now I am going to look at converting our Windows database code to
using an ADO based module.  One weird thing is that the
RecordSet.GetRows function returns stuff in a weird (Columns, Rows)
format, instead of the (Rows, Columns) that we need.  My first pass at
a python function to transform that is disappointingly slow.

I am also concerned about the proliferation of ADO library versions
out there.  Our product supports Windows NT4 (Service Pack 6) through
XP -- and we'd prefer not to have to redistribute any libraries.
Right now I'm playing around with ADO 2.5, though I think they're up
to at least 2.7 now.


> Search Google for the full answer, but when Python COM servers return tuples
> to VB clients, the clients can't understand the data.  Lists, however, come
> back as variant arrays. Mark Hammond has posted the reason for this, but I
> don't remember it.

OK.  Well in our case, we would be doing Python <-> Python calls only,
so I wonder how it would handle that.  I'll check the archives.

thanks for the response!

Preston Landers