Thanks! > I don't quite understand what you mean by TCP/IP queue; Suppose Web server code thread A sends a request to session state store (server) thread X in

Thanks! > I don't quite understand what you mean by TCP/IP queue; Suppose Web server code thread A sends a request to session state store (server) thread X in another AppDomain, process, address space, virtual machine, physical machine, etc. About the same time, threads B, C, D, ... similarly send requests to thread X. Now, suddenly, poor thread X is working on the request from the TCP/IP session from thread A. So, what the heck happens to the requests sent to X from B, C, D, ...? Even if thread X does the work of thread A in one millisecond, the requests from the other threads might all arrive in just 10 microseconds during the 1 millisecond. So, there has to be a place, a queue, in the TCP/IP stack at thread X for the requests B, C, .... So, a standard part of the design of TCP/IP for receiving such requests is a queue. Well, of course, we want a first-in, first-out (FIFO) queue. And the storage for the queue will be finite. It turns out, the queue depth, IIRC, can be set, adjusted, by ordinary system management of the TCP/IP stack software. So, if my server farm has 100 Web server threads and only one session state store, then that session state store can get at most 100 requests at once. So, a queue depth of 100 should be enough! Now, sure, think about Microsoft's IIS (internet information server) that starts threads in my Web server software; want IIS to start no more than 100 threads! So I'll need to check on how to do this. In that case, some user 101, when 100 users are already waiting, will have to wait before IIS creates a thread for them. Then, sure, should arrange a graceful way to handle that overload situation, e.g., send that user 101 a message about the site being too busy. This issue of the site being too busy is bigger than that and likely needs more careful thinking than just some one parameter in IIS. > The scalability of your system depends entirely on the standard collection class, which will be OK but not optimal. The session state store collection class is all in main memory and blindingly faster than the real work for the users; some of that real work involves skipping down a SQL Server table with a clustered key -- the table is on rotating hard disk! Sure, SQL Server may cache in main memory some of the data; as SQL queries go, it's quite fast, e.g., no joins and only that one table; since the SQL Server table is read only except for maybe write once a week, that table is a candidate for some solid state disk; still, even on solid state disk, the time for the session state store is only a tiny fraction of the work, and wall clock time, for serving one user request, small potatoes, and not a main candidate bottleneck. > You've not described an authentication mechanism, so it has to be kept firewalled - a lot of people have made the same mistake with memcached. Thanks for the authentication issue! So, maybe I should consider adding checks on the IP addresses to make sure they are as expected within my server farm! Nice!! Maybe I should also talk to Cisco! All the servers are inside the server farm, and it is supposed to be nicely firewalled from the public Internet by my router(s), e.g., just using IP addresses that don't work on the public Internet. Sure, if someone gets some malware running inside my server farm, then I'll have a fox feasting in the chicken coop. On one client blocking: Hmm .... Maybe! NICE point. So, a Web server sends a key to the session state store (server) key-value store requesting a value for the session state for the user identified with the key. The session state store looks up and returns the value, but in the meanwhile the Web server thread waiting, via its TCP/IP stack, on the session state store goes belly up and dies. So, the TCP/IP stack at the session state store will eventually notice the bad TCP/IP session, the failure at the other end of the wire, and give my session state store a timeout. My session state store, noticing the timeout from its TCP/IP stack, will write a note to the log file and continue on. The time for the time out (which I should set to be short) will hold up all threads that depend on that session state store. Since 99+% of the work at the Web site is NOT going to/from the session state store, nearly all the real work of the Web site can continue while the session state store thread waits for the time out for its session with the dead Web server thread. The next HTTP POST from a user should cause Microsoft's code, IIS (Internet Information Server), to start another executing instance of the Web server software which will, on a good day, let the work continue. Users with work in progress might get something unresponsive and, if they POST again, get a message from the fact that the Web server code notices that the user's state is not right, or maybe it still is right and okay and the user is not bothered. The time involved might be only a second or few and not too bad. My Web site is not dealing in money or crypto tokens, etc. And my users don't log in, and I'm making no use of cookies. So, for such an error, about the worst that can happen to a user is a lost logical interactive session, which is no threat to the solar system! NICE consideration! Thanks!