What are the effects of IIS's app pool setting for recycling to recycle after "Fixed number of requests"?
Suppose this number is 100, and the 99th person connects to my web site, then the 100th person comes and will trigger an application pool recycle.
Does this mean all session information for sessions 1-99 will be lost (in-process session will expire when application pool worker process restarts)?
You basically have it right, but it's not the person, it's the request. Each aspx page called on your application will add up and when the threshold is reached, the application pool is recycled, the application domain (if your using .Net) is unloaded and everything starts up again. You lose Session, Application and any static variables laying around. If your using classic asp or php, every session and global variables are lost too.
A number of hits threshold is a bit overkill. You should either disable it or set it to a huge number. By default, if I recall well, the IIS6 application pool recycles every 15 minutes if there were no request and you can also put threshold on the total memory used by your application to trigger recycling.
That is quite correct. If you do not use some kind of Session farm, or database backing of the session information, it will be lost when the application pool is recycled. I would recommend trying hard to not require any session information - this will make your application more scalable and reliable as it maps more closely to the stateless nature of the underlying HTTP.
