The biggest problem with 280, mostly idle, threads would be the amount of stack space the OS is required to reserve (1MB for Windows/2MB for Linux). On a 64bit host this is unlikely to be much of an issue.
On Mon, Dec 15, 2014 at 6:11 AM, Pieter Hintjens <p...@imatix.com> wrote: > > 280 threads sounds fine unless you have data showing that it's a > problem. That's easy to test on your target platform. > > On Sun, Dec 14, 2014 at 7:54 AM, Bob Clarke <optiongu...@gmail.com> wrote: > > Platform: 0MQ 4.0.4 on Windows 7/Windows Server 2008 > > > > I am writing a server monitoring program to replace an ancient (1999) > > program that is almost impossible to maintain. > > > > All of our application servers host proprietary Windows services written > in > > C++ (except for a couple .Net apps) that use a proprietary synchronous > > request/response system (it works very well, has been for many years, and > > isn't being replaced any time soon). > > > > The monitoring program sends test scripts to the server apps and waits > for a > > reply. In most cases, the reply is almost immediate, but in some cases, > > there could be a delay of up to 30 seconds. So, to avoid one script > causing > > delays with others, each test script runs in its own thread. This thread > > must send its results back to a listener, so it creates and uses a 0MQ > > socket to do so. Each test script has a repeat interval; some are run > every > > five seconds, but most are run every 45 seconds, 90 seconds, or less > > frequently. > > > > There are about 280 test scripts (we have thousands of servers across > three > > data centers), so I seem to have two unfortunate choices: > > 1) Keep the script threads around so I'm not creating and destroying a > > socket each time a test runs; > > 2) Let the script threads terminate so I am not keeping 280 threads open > at > > once. Since the script repeat intervals are quite long in computer terms, > > these threads will spend most of their time do nothing. > > > > I lean towards the first option, but opening and closing sockets that > often > > doesn't sound good. Then again, keeping 280+ threads around doesn't > sound so > > great, either. > > > > So before I go too far down this development road, does anyone have some > > experience they could share? > > > > Thanks. > > > > Bob > > > > > > _______________________________________________ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
