Overcoming python performance penalty for multicore CPU

[John Nagle]

Paul Rubin wrote:
> John Nagle <nagle at animats.com> writes:
>> Analysis of each domain is
>> performed in a separate process, but each process uses multiple
>> threads to read process several web pages simultaneously.
>>
>>    Some of the threads go compute-bound for a second or two at a time as
>> they parse web pages.  
> 
> You're probably better off using separate processes for the different
> pages.  If I remember, you were using BeautifulSoup, which while very
> cool, is pretty doggone slow for use on large volumes of pages.  I don't
> know if there's much that can be done about that without going off on a
> fairly messy C or C++ coding adventure.  Maybe someday someone will do
> that.

    I already use separate processes for different domains.  I could
live with Python's GIL as long as moving to a multicore server
doesn't make performance worse.  That's why I asked about CPU dedication
for each process, to avoid thrashing at the GIL.

    There's enough intercommunication between the threads working on
a single site that it's a pain to do them as subprocesses. And I
definitely don't want to launch subprocesses for each page; the
Python load time would be worse than the actual work.  The
subprocess module assumes you're willing to launch a subprocess
for each transaction.

    The current program organization is that there's a scheduler
process which gets requests, prioritizes them, and runs the requested
domains through the site evaluation mill.  The scheduler maintains a
pool of worker processes which get work request via their input pipe, in Pickle
format, and return results, again in Pickle format.  When not in
use, the worker processes sit there dormant, so there's no Python
launch cost for each transaction.  If a worker process crashes, the
scheduler replaces it with a fresh one, and every few hundred uses,
each worker process is replaced with a fresh copy, in case Python
has a memory leak.   It's a lot like the way
FCGI works.

    Scheduling is managed using an in-memory
table in MySQL, so the load can be spread over a cluster if desired,
with a scheduler process on each machine.

    So I already have a scalable architecture.  The only problem
is excess overhead on multicore CPUs.

				John Nagle