In the WebSocket++ 0.3.x library, what determines the limit of how many WebSocket clients can have an active connection? Is it one connection per thread, or can one thread handle multiple WebSocket client connections? If it is the latter, roughly how many connections can one thread hold?
Basically, I'm looking for a ballpark number of how many client connections WebSocket++ library can handle in a application with roughly 25 threads to spare. The library homepage is:
http://www.zaphoyd.com/websocketpp
If you are using the Boost.Asio based transport policy with a recent version of Boost on a platform that supports non-blocking/asynchronous I/O (epoll on Linux, kqueue on OS X/BSD, iocp on Windows) then WebSocket++ does not introduce any significant limits on simultaneous connections.
In such situations, the limits are pretty much based on OS, hardware, and application factors. The OS will limit total file descriptors in use per process (with root access this limit can be changed). High concurrency levels will require your application to be structured appropriately to handle it (primarily using short, bounded time, non-blocking handlers). Other factors will limit you in the same way that generic servers will be limited. Gigabit Ethernet can only handle so much traffic, using TLS or compression will reduce performance, etc.
I haven't done extensive performance benchmarking with 0.3.x yet, but 0.2.x in appropriately tuned applications were able to easily service 10s of thousands of concurrent clients on an i7 core.
It is the intention of the WebSocket++ architecture to scale to arbitrary connection counts given sufficient resources. If you are working on an application that scales WebSocket++ beyond 10k connections I'd be interested in more details and in addressing any bottlenecks you discover.
