2009-10-26: Update
It looks like Sourceforge is linking to the wrong version on the project page and everything (e.g. svn info) is way outdated... and they don't make it very easy to administer projects anymore. I'm not so sure why I'm still with SF actually. </rant>
Please double-check that you are running 1.1.0-rc4 or later. FYI, the step to 1.1.0 when it arrives will be small in terms of code changes, most bugs are accounted for now.
Links
About PyISAPIe
PyISAPIe is an ISAPI extension for Windows-based web servers that allows Python scripts to be used to serve web pages. The main web server this extension runs on is IIS, although it will run on Apache web servers as well.
The reason ISAPI applications have the capability of being better than CGI or FastCGI applications is mostly due to its tight integration with the web server environment. Instead of initializing an entire program from scratch (in this case, the Python interpreter) every time a request is made for a page, an ISAPI extension only has to provide a function that is called upon every request. For interpreting Python scripts on a per-request basis, this means that the interpreter can be initialized once and used many times, creating a very noticeable performance gain.
PyISAPIe is WSGI compliant (except for readline support). Because there aren't yet a lot of publishing tools to go with this package, I recommend using Django if you're looking to publish pages right away. I have included am example WSGI handler script, so if you know Django you shouldn't have too much trouble getting going with it.
News / Thoughts
Random Python and web service related stuff.
GIL Modification Proposal
This is a followup to my thoughts below about speeding up Python/PyISAPIe. I've submitted a ticket to the Python tracker and got a discussion going on the Python-Dev mailing list... so we might see a great improvement in multithreaded Python code soon. Perhaps someday, when I have more time (ha), I can figure out how implement the GIL as a futex in Linux. Or something faster anyway.
Making Python faster, the hacker's way
I've been experimenting with some ways to make PyISAPIe faster. Not because it isn't fast already, but because it's the most fun I have after my code works - I get a chance to break it on my quest for Ultimate Speed :)
I've been working on two things lately:
Embedding the Python core into PyISAPIe
I've done it before and the performance results were so-so. I think this option will be viable, if anything, as a convenience package (no Python install necessary).
Making GIL locking/unlocking faster
So far this looks promising. The GIL is operated by a Windows "Event Object," which is possibly the slowest synchronization option available under high concurrency. The system-level mutex would be a better choice, but that wasn't fast enough for me so I chose the most lightweight option: a critical section.
I had to cheat the non-recursive part in a way that some would not appreciate because critical sections are recursive by design. Recursive is good because it prevents deadlocks, and bad because it can make debugging a nightmare.
Apparently my fake non-recursion is enough for now - not only does all of my Python code work, I'm getting (NON-scientific!) benchmarks that are almost twice as fast.
I don't know why events were chosen as the method for GIL locking/unlocking. Even if Windows 95 support is absolutely necessary (meaning no "official" TryEnterCriticalSection), system-level mutexes are still available (via CreateMutex et al). At least the base-case of one single thread is fast thanks to the hybrid interlocked compare-exchange checks, but that is also accomplished by critical sections.
If anyone is interested in discussing this more, feel free to get a thread going on the mailing list.
The old Blog site has finally been recovered, but I'm not sure if I plan to continue using it. For those who were wondering, SourceForge likes to silence PHP errors and produce pretty blank pages in order to make debugging "textless." That was fun ;)
