WOW! Thanks. > hooking into session management to track request state all over the place is something of a siren song Yup. The scary part is to discover tha

WOW! Thanks. > hooking into session management to track request state all over the place is something of a siren song Yup. The scary part is to discover that occasionally, and too often, the site gets sick, and due to non-determinism, etc., I can't easily reproduce the behavior to analyze it, find the cause, and correct it. Using a log file, etc. to trace the work in detail of each user for some 60 second interval that showed the problem is likely a siren song, big muddy swamp, but, still, maybe one of only a few choices with any promise. I'll be thinking of such tracing as I continue to get my code ready for production. Right, turn on full tracing, run for two weeks, get a 20 TB log file, and discover that somehow with the tracing on don't get the problem!!!! Nightmare scenario!!! My home brew, DIY, roll your own, just some serialization, TCP/IP sockets, and two instances of a standard .NET collection class, session state store (server) has worked fine in my testing so far. The session state server has been one of the easiest parts of my code and work so far. Some TCP/IP, serialization and two instances of a collection class should not be considered a challenging development or debugging job!! But currently I'm doing some grunt work, ..., and racing to go live on the Internet. So, currently I have 0 users per second. When I get to 1 user a second, that will be a big day. You are correct: I'm a sole, solo founder, CEO, CFO, CIO, ..., software manager, server farm manager, ..., software installer, cable puller, etc. so, could easily change all my Web site software to use a different session state store. Uh, I've already designed the Web server software and session state store so that there need be no user affinity between users and a particular executing instance of the Web server software. Generally as you suggested, since I'm a solo developer, who still does good documentation, it's easy for me to make some likely changes, much easier than if I had rows and columns of developers filling floors of a 20 story building with 300,000 square feet of space. My planning for implementation now is for 1 to a few users a second, on average, 24 x 7. I do want to look at the whole server farm architecture and determine just what would happen, where my site would break, at, say, 100 users a second, from a DDoS attack, an article in the the tech press, something viral, etc. Maybe Cisco has a box that could help me. So, if the site is overloaded, then I want the users to get a simple message back apologizing for the overload or at least just a slow response. Basically I want to know where the performance bottlenecks and limitations are and have just one bottleneck that can handle the overload gracefully and throttle what reaches everything else. Heck, the electrical system has circuit breakers; electronics commonly has overload protection; my Web site should, too! For 10, 100, 1000 users a second, each of those steps is a factor of 10 more. Point: Factors of 10 are not just different quantitatively but different qualitatively. At 100 users a second, I'll be hiring for the 100 and also planning for 1000 and 10,000. I'll be thrilled at 1 user a second, but there is a chance that people will like my work and cause usage to grow to 1000 users a second. Good to know that some people already know how to handle 200K/second!!! Thanks!