When you look at the most highly scalable web applications (or services) today, the problem wasn't ensuring enough threads that were available, but ensuring the whole system could handle the concurrent web connections required to service the endpoints.
The biggest advancements in concurrent requests/second on one installation came from non-blocking I/O. Essentially, the operating system has the means of letting the application when a new client as connected, and when new bytes arrive. A single thread can handle multiple thousands of asynchronous connections as long as the non-blocking I/O is fully supported by your system.
A system can have too many active threads at once. When that happens, the operating system is spending more time switching contexts between threads than executing work within the thread. Having a global thread pool with a finite number of threads to process asynchronous I/O with an asynchronous platform will help the efficiency of handling thousands of requests per second. It's probably best to have the total thread count a multiple of the cores on your machine (across all CPUs).
Another very common answer to scaling is to simply have more servers hosting your application or web service. Each server is in it's own process, many times on separate hardware. If there is a proper "shared nothing" architecture then you can simply scale out as much as your load balancer allows.