Blasting past 8000 concurrent SMB connections!
This morning we blasted past 8K concurrent connections to our SMB stack. We were originally trying to get FSCT running and we’re pretty close – we’ve run into client side configuration issues and controller side issues and we’re working with Microsoft to get these resolved. I’m probably going to head up there in the next couple of weeks and figure out how we can collaborate on making sure that fsct is tested against non-Windows SMB servers
In the interim, Brian fixed up our redirector to force it to open multiple connections out to the Likewise CIFS stack. I’m sketchy on details – the idea is to force a single connection on a per user. So 10K users will translate to 10K connections on the server.
Once we did this, Jerry ran the test this morning and we blitzed past 8K SMB connections. We hit this limit because server was hard-wired to do a max of 8K connections. Once we turned this off, we’ve seen this go way past 8K. Our belief is that we will scale to the resource limits on the server.
Note that the test shows that the stack can create the necessary data structures for 8K SMB sessions (or greater). We still need to test i/o throughput numbers. We want to ensure that when you have 10K or greater SMB sessions, given that the server will statisically multiplex (some connections will be doing active I/Os while other connections are idle), the active sessions can deliver reasonable throughput guarantees.
My own system service design schooling was always thread-based systems. And at Microsoft, we always wrote thread based single process systems. So it was surprising to hear from several people in the open source world that threads are bad and evil and you can’t get decent performance guarantees using threads. lwio is our single process multi-threaded architecture and so far we seem to be doing okay. Perhaps we’ll get tripped up somewhere, but right now its looking pretty good.
