CGI works on most web servers, where it forks an environment to run the process. This gives you a robust solution, poor scripts can't pollute the web server, or each other, however each fork takes CPU cycles and memory, so CGI is slow.

In Process technologies like mod_Perl or ASP load the interpreter into the webserver on start up and all the scripts are compiled into the server. This avoids the overhead of forking each time a request comes in, so it's much faster, but any leak in your code, and the leak goes into the whole process - you MUST write your code tight to avoid any problem.

ASP is a proprietary MS technology and only runs on IIS, which isn't very stable, secure and only has 25% of the market. There are ways to run ASP via emulation in mod_Perl - it's supposed to be faster than MS's ASP, but it's not 100% compatible.

Most of the time you can get by, by writing your code for CGI, it's easier to test and develop on, and it's robust so unless you have a lot of traffic it's usually good enough.

See also:

• Perl/CGI Performance for a Shopping Cart
• Shopping Cart
• Building a Large-scale E-commerce Site with Apache and mod_perl
• Mod_Perl home page.
• mod_perl installed but not faster
• mod_perl vs CGI: benchmarks and code
• How do you feel about mod_perl?
• How common is mod_perl?
• Perl/CGI Performance for a Shopping Cart
• mod_perl Developer's Cookbook