On Thu, Sep 25, 2014 at 01:49:13PM +0200, Arnaud Kapp wrote:
> Hello everyone,
>
> Not too long ago I asked about POLLPRI being handled by ZMQ for a
> particular project i'm working on. I am still figuring out if ZMQ would be
> a good fit in this project. I would like your feedback about my use case,
> and your insight about performance problems I may encounter.
>
> I've read that when using ZMQ one shouldn't have to spawn many sockets.
> However, when thinking about my design I realized I'd be having a lot of
> socket talking to each other (locally, through inproc://).
>
> Each component of the software would somehow be like a ZActor. The a pipe
> socket back to parent thread, a REP socket for other component to connect
> to, and a PUB socket to publish event. (With an average of 100 component --
> each with no "cpu intensive task"). The breakdown in multiple actor thread
> would be for clarity, not performance (not all target computer have more
> than 1 thread anyway).
>
> I'd say a worst case scenario would around 500 - 1000 sockets. It should be
> less than that most of the time though.
>
> The messages activity is not stable. Most of the time I wouldn't expect
> more than a dozen message per second being sent, but sometimes it would be
> more. (300 - 400msg per seconds being published, plus the "control traffic"
> through REQ/REP).
>
> This software target low performance ARM device (raspberry pi mostly). I
> know its not easy to tell based on what I just wrote, but do you think I
> risk performance problem?
> Do you think the design is "zmq approved" ?
You probably should have a master thread that binds a few sockets and
then start your 100 components as worker threads. Each component
connects to the master and communicated over that with the rest of the
world. That way you have more like 100 sockets instead of 1000.
MfG
Goswin
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
