If you’re following the 3.1.0 thread, then you know siege clients are essentially capped by your operating system’s FD_SETSIZE. For most of us, that means 1024. You can increase its capacity by recompiling your kernel, an operation Your JoeDog hasn’t attempted in over 20 years. In all likelihood, you don’t feel like doing that either.

To overcome this limit, we switched from select to poll in siege-3.1.0 rc2. If your OS supported poll, then you’d use that mechanism to test socket readiness. So while that increased our capacity, it wrecked our performance. Why? It’s still not clear why but that’s the feedback we received from several testers. It also matches our own experience.

Which brings us to release candidate 3. We now use both mechanisms. If a socket descriptor is less than FD_SETSIZE, then we test it with select. If it’s greater than that, we use poll. Thus far it seems like a good compromise until we develop better method for high volume socket testing.

NOTE: If your web server is not configured to run a pool of 1024 threads, do NOT configure siege with that many simulated users. If you use more siege threads than available web server threads, connections will back up while waiting for handlers and before you know it, you’ll have a mess. You’ve been warned. 

http://download.joedog.org/siege/beta/siege-3.1.0-rc3.tar.gz