Some notes on a high-performance Python application.

Heiko Wundram modelnine at modelnine.org
Wed Mar 26 14:15:32 EDT 2008


Am Mittwoch, 26. März 2008 18:54:29 schrieb Michael Ströder:
> Heiko Wundram wrote:
> > Am Mittwoch, 26. März 2008 17:33:43 schrieb John Nagle:
> >> ...
> >>
> >>     Using MySQL as a queueing engine across multiple servers is unusual,
> >> but it works well.  It has the nice feature that the queue ordering
> >> can be anything you can write in a SELECT statement. So we put "fair
> >> queueing" in the rating scheduler; multiple requests from the same IP
> >> address compete with each other, not with those from other IP addresses.
> >> So no one site can use up all the rating capacity.
> >> ...
> >>     Does anyone else architect their systems like this?
> >
> > A Xen(tm) management system I've written at least shares this aspect in
> > that the RPC subsystem for communication between the frontend and the
> > backends is basically a (MySQL) database table which is regularily
> > queried by all backends that work on VHosts to change the state (in the
> > form of a command) according to what the user specifies in the (Web-)UI.
>
> I vaguely remember that this database approach was teached at my former
> university as a basic mechanism for distributed systems at least since
> 1992, but I'd guess much longer...

I didn't say it was unusual or frowned upon (and I was also taught this at uni 
IIRC as a means to "easily" distribute systems which don't have specific 
requirements for response time to RPC requests), but anyway, as you noted for 
Biztalk, it's much easier to hit bottlenecks with a polling-style RPC than 
with a "true" RPC system, as I've come to experience when the number of nodes 
(i.e., backends) grew over the last year and a half.

That's what's basically causing a re-consideration to move from DB-style RPC 
to socket-based RPC, which is going to happen at some point in time for the 
system noted above (but I've sinced changed jobs and am now only a consulting 
developer for that anyway, so it won't be my job to do the dirty migration 
and the redesign ;-)).

-- 
Heiko Wundram



More information about the Python-list mailing list