Paul Simon wrote: > I currently have CGI pages caching on the client side, which > is helping some, but I'm also going to experiment with CGI::Cache.
There are some mod_perl specific version of this too, like the one from the mod_perl Developer's Cookbook (Apache::CacheContent), but these are mod_perl 1.x and probably require work to get them running on mod_perl 2. Traditionally this has mostly been done with a caching reverse proxy, and that's another angle you could try. > What kind of trouble is > there for having use DBI and use HTML::Template in both startup.pl and > Snoopy.pm (besides being redundant)? None. That is the right thing to do, because it preloads the modules (by having them in startup.pl) and documents the dependencies (by putting in Snoopy.pm). > Since Snoopy.pm is the meat and > pototoes, should it also be in startup.pl? Yes. > Does declaring Class > variables, such as the DBI handle, offer any benefits (or pain) of a > shared connection? You're getting yourself into major trouble there. You should use Apache::DBI instead. The way you have it now (with the connection code in the "main" section of Snoopy.pm), that database connection will be created when you use the module in startup.pl. Apache will then fork and multiple children will try to share the same $DBH. Disaster. Also, your solution will not try to reconnect if it loses its connection. Apache::DBI will. And you are creating a closure here with your $DBH which might come back to bite you later if your module gets automatically reloaded when you change it. - Perrin
