Practical mod_perl

Appendix C. ISPs Providing mod_perl Services

This appendix proposes a few techniques for deploying mod_perl on ISP machines. Therefore, it’s mostly relevant to ISP technical teams and ISP users who need to convince their providers to provide them with mod_perl services.

There are at least four different scenarios for deploying mod_perl-enabled Apache servers that ISPs may consider:

• Users sharing a single web server

• Users sharing a single machine

• Giving each user a separate machine

• Giving each user a virtual machine

This appendix covers each of those scenarios.

Users Sharing a Single Web Server

An ISP cannot let users run their code under mod_perl on the main server. There are many reasons for this. Here are just a few to consider:

Memory usage

One user may deprive other users of memory. A careless user’s code might leak memory due to sloppy programming. A user may use a lot of memory simply by loading a lot of modules. If one user’s service is very popular and gets a lot of traffic, there will be more Apache children running for that service, so it’s possible for that user to unintentionally consume most of the available memory even if she has a very small, well-written code base with no memory leaks.

Other resources

It’s not only memory that is shared between all users. Other important resources, such as CPU, the number of open files, the total number of processes (currently there is no easy way to control the number of mod_perl processes dedicated to each user), and process priority are ...