[python-win32] Question on server architecture

[Don Dwiggins]

I have an architectural question:

Background:
I currently have a program that handles long-running requests on behalf of
web clients.  Essentially, the flow is:

1) The client (an ASP page) fires up an instance of the program, with
   arguments to begin the request processing (which will store its results
   in a database).

2) Subsequent requests "ping" the program to determine the status of the
   processing.

3) When the return is "finished", a redirect is done to query the database
   and format the results for the initiating user.

(I've glossed over several details of the requestors, which aren't important
here.)

Currently, the whole thing is tied together by a generated token I call a
"session ID" (nothing to do with ASP sessions).  The program, on startup,
creates a named pipe whose name includes the ID; the ping requests "call"
the program using the pipe.

This works, but it's proving to be less than ideal for a few reasons:
- If a few requests come in at once, the processor load spikes; it can take
  several seconds for the program to get going.  
- Also, the ping requests seem to have a heavier impact than I'd thought.
- In addition to web requests, I'm using as a client a scheduled process,
  run by the Cygwin cron daemon.  This means that the process runs under the
  LocalSystem account, which oddly enough can't use named pipes (which must
  have names in a UNC format, which LocalSystem doesn't have access to).
  For this reason, I have to use a different scheduler started up under a
  logged-in user account.

Oddly enough, when I ran stress tests on this setup, it was able to handle
many simultaneous requests.  The difference is that the stress test was
using anonymous web clients, while in production the site uses integrated
authentication.  I'm not sure why this should make a difference, but it
does.  The result is long wait and execution times for the ASP requests.


Question:
I'm thinking of replacing the per-request process by a long-running process
that takes requests by registering itself as a COM server.  The problem is,
I'm not sure that this approach will work.  The idea is that the client
would instantiate an object to make the initial request, then dismiss the
object.  The ping requests would operate similarly.  Thus, between requests,
the server would continue (presumably in different threads) running the
request processes.  Can anyone give insight as to whether this can/can't
work?  (I'll probably experiment with it, so I may have more to say if
anyone's interested.)

If you've gotten this far, thanks for your attention and any good words...
-- 

Don Dwiggins                     "The truth will make you free,
d.l.dwiggins@computer.org         but first it will make you miserable"
                                  -- Tom DeMarco