rpyc performance problem solved - but why?

367 views
Skip to first unread message

Jeff

unread,
Oct 2, 2009, 6:11:05 PM10/2/09
to rpyc
Hello Everyone,

I finally was able to solve the performance problem that I encountered
in my rpyc application. But I don't understand why my solution
worked, and I'd appreciate any insights that you might have.

My application consists of a chain of processes, each talking to the
next using rpyc. When I began, each process in the chain used a
BgServingThread to keep the next process responsive. But what I found
was that the BgServingThread didn't have the effect I thought it would
- instead, I would see some of the processes hang, or at a minimum
slow down drastically. I am now avoiding the problem by adding an
explicit conn.serve() in the main loop for each process.

But why does this work? It seems to me that my explicit conn.serve()
call is doing the same thing that BgServingThread does, except that
it's not running in a thread. Maybe somehow the thread that my
BgServingThread runs in has died? How would I know?

Jeff

Marcin Cieślik

unread,
Oct 2, 2009, 6:35:11 PM10/2/09
to rp...@googlegroups.com
Hello,

>  Maybe somehow the thread that my
> BgServingThread runs in has died?  How would I know?

Maybe it starved?
http://linuxgazette.net/107/pai.html (look into section 2.1)

Yours,
Marcin

tomer filiba

unread,
Oct 13, 2009, 9:29:58 AM10/13/09
to rp...@googlegroups.com, marcin....@gmail.com, jstro...@hotmail.com
Maybe somehow the thread that my
BgServingThread runs in has died?  How would I know?

yes, well, i suspect marcin is right. the thread most probably did not die (or you would get a traceback printed on the screen) -- it's simply that the two threads lock a mutex on the connection (so they don't trash each other's data). for some reasons, the standard thread.Lock mutexes behave very weird in rpyc (and in python in general). the seem to cause starvation.

see also:
http://groups.google.com/group/rpyc/browse_thread/thread/7a3b79543a0a6439
http://groups.google.com/group/rpyc/browse_thread/thread/1025bade530c3eca


if you can avoid using threads sharing the same connection, it's probably the best practice.

-tomer

An NCO and a Gentleman

Jeffrey Stroomer

unread,
Oct 13, 2009, 10:56:44 PM10/13/09
to tomer...@gmail.com, rp...@googlegroups.com, marcin....@gmail.com
Tomer,

Thanks for the help - the explanation seems plausible.  Before my fix my code looked a lot like Cihat's example.

I had so much trouble solving the performance problems that I honestly thought I might have to give up.  But once I stumbled on the solution, the performance was excellent.

Jeff


Date: Tue, 13 Oct 2009 15:29:58 +0200
Subject: Re: [rpyc] Re: rpyc performance problem solved - but why?
From: tomer...@gmail.com
To: rp...@googlegroups.com
CC: marcin....@gmail.com; jstro...@hotmail.com

Hotmail: Free, trusted and rich email service. Get it now.
Reply all
Reply to author
Forward
0 new messages