Yes, each application pool is typically a single process1, but can contain multiple threads. You can assign multiple sites to an application pool, and those sites will all run under the same process, however they will run under different "app domains", which are security contexts that separate the code of one site from another, even if they're running on the same app pool.
Two users hitting the site at the same time can run on different threads, meaning they can run concurrently. That means any logging can have values interspersed. You might want to add a session value to your logging so you can sort based on session.
App pool restarts (recycling) are normal, 20 restarts in a day does not seem unusual. They can happen multiple times per day, and IIS controls when app pools are restarted. It does this whenever it feels it needs to clean up the pool.2 Your applications should be written in such a way as to recover gracefully from this (ie, do not keep anything in session that cannot be easily recreated if the app pool restarts).
The app pool can also restart when an unhandled exception occurs in your app. In that case, you want to address the cause of this. Such exceptions are usually logged in the event log.
1 – While you can configure an application pool to have multiple worker processes (this is known as a Web Garden), this is not a typical (nor generally recommended) configuration in my experience.
2 – Note that using IIS Manager you can configure an application to log recycle events to the Windows Event Log. You can also use IIS Manager to set the threshold for when several of the different types of recycle events occur.
Best Answer
What happens during an IIS restart is actually a roll-over process. A new IIS worker process starts that accepts new connections, while the old worker process continues to process existing connections.
This means that if you configure your load balancer to use a balancing algorithm other than simple round-robin, that it will tend to "naturally" divert some, but not all, connections away from the machine that's recycling. For example, with a "least connections" algorithm, connections will tend to hang around longer while a server is recycling. Or, with a performance or latency algorithm, the recycling server will suddenly appear slower to the load balancer.
However, unless you write some code or scripts that explicitly detect or recognize a recycle, that's about the best you can do--and in most environments, it's also really all you need.