My confusion is, if thousands of requests come in for a particular servlet, then all those processes will be created in application server putting pressure on application server resources. That means problem has moved from web server to application server. How does it solve the problem ?

Often times an application server will be written to use threads instead of processes because of exactly the problem that you describe. But this is only one of the many benefits of moving away from such antiquated technologies as CGI.

When using vanilla CGI and perl, the following things to happen when the CGI script is invoked; load the perl interpreter, parse the code, load any modules used, connection to any databases and then execute the code. If you use an app server or even something as simple as FastCGI you can pre-load the perl interpreter, your code and any modules you are using as well as pool database connections. This means that for each web request you are just simply running your main code, nothing else. This is not only a CPU savings, but it is also a memory savings.

A decent app server may also provide other nice things such as hot-code reloading (loading in new code without server restart), ability to run multiple versions of code simultaneously, in process debugging or REPL (read-eval-print-loop) and more.

You are correct in saying that this means the "problem has moved from web server to application server", but this is a good thing. With CGI, you are 100% in control of your particular process and it is completely isolated, this is fine for quick and dirty solutions that aren't going to grow. But as soon as you move beyond this to a larger and more complex web application (if this were Java I would be calling it "enterprise"), the benefits of having pre-compiled modules and pooled database connections is much more obvious. It is at this point that you want an app server that has already figured out these hard details for you so that you can focus on writing your app and not basic plumbing.

I don't think there is some magical way around this problem. If you need to serve thousands of requests in parallel, you'll need to have the respective server resources to do so... (This might mean having a cluster of machines with load sharing, in case an individual machine can't take it.)

Switching from CGI to some persistent environment (like mod_perl, FastCGI) essentially only reduces the startup overhead per request. This might, however, help to some degree, if the actual request handling only takes a short time. In other words, if the startup makes up a substantial part, reducing it can help increase the overall server throughput...

In (my) simple terms: If that servlet is held in memory after being called for the first time, you save the repeated loading of the code for each request. This doesn't happen if you are using a CGI script. Each call of the CGI script causes the server to read the script file from hard disk (or wherever it is stored) (and interpret it) and execute it. If there are a thousand requests of that script, it will be loaded from disk for a thousand times...

As we don't know what you exactly mean with servlet, I think of the difference between mod_perl and "plain" CGI. Others, who have a deeper insight in this topic may be able to provide further details, documentation links or corrections of my words.