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" ? -- Kapp Arnaud - Xaqq
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
