Advanced Topics

There are two setup issues that go beyond the normal installation however which some readers will definitely care about. If you are a beginning or intermediate reader, you can feel free to skip this section. The information here is not necessary for a basic installation and customization project.

[ TOC ]

It is probably worth mentioning that including configuration parameters within the application executable is not the only setup architecture that you could use. In fact, in the last edition of this book, Instant Web Scripts, we recommended using standard setup files to configure applications.

In this edition we changed our design to put configuration in the executable itself for two reasons:

1. Putting configuration information in the executable is more secure.

2. Putting configuration in the executable allows for easier integration with mod_perl.

[ TOC ]

Putting configuration into an executable makes it less likely that a cracker will be able to read your sensitive configuration information. While it is possible that if there is an error with the web server that CGI files might become readable as text, that problem would be very rare indeed.

It is far more likely that a web server will be configured to allow setup text files to be read by a web browser. Though we have always been careful to let users know that they should move sensitive files such as setup files out of the web documents tree, we find that many users fail to heed our warnings.

Thus, putting configuration data in the executable itself is one way we proactively protect our users.

[ TOC ]

Putting the configuration information in the executable also makes it easier to integrate with perl accelerators like mod_perl that cache the contents of files for efficiency. If we were to load a setup file into an application under a mod_perl environment, we would have to be very careful to make sure that the namespace of the setup library was protected. As you will see in the next section, this can be a real pain.

[ TOC ]

As we just said, it is actually possible to read a setup file from any eXtropia application. However, to maintain mod_perl compatibility, if you want to do so, you must go through a few back flips.

BEGIN { use lib qw(./ExtropiaAppAdminFiles/Modules); use strict; use CGI; use CGI::Carp qw(fatalsToBrowser); use vars qw( $CGI ); $CGI = new CGI(); require ("setup_file.pl"); delete @INC{$SETUP_FILE}; }

Further, in any setup file, you must be careful to declare all variables using use vars because the my declarations will not carry over to the executable.

$SAMPLE_VAR = 1; use vars qw($SAMPLE_VAR);

[ TOC ]

One of the most frequently asked questions is How do I speed up my CGI script? Well, there are several ways which we will discuss here.

[ TOC ]

One thing you should consider when configuring eXtropia applications is that some of our modules rely on modules from CPAN. Some of those modules may be fairly heavy and could add to the load time of your application.

For example, if you are using an eXtropia::DataSource with a date data type, we load Date::Parse to parse the date formats. If you do not wish to load this module, we recommend that you turn this field in your data source into a string data type.

The same goes for the use of date validation using eXtropia::DataHandler. Many of the functions in this data handler make use of Date::Parse as well.

If you are worried about module dependencies, we suggest that you read the relevant chapters related to those modules for their dependencies. A quicker way to do this is to use the perldoc utility on the specific driver to see what dependencies it relies on.

[ TOC ]

Most web sites work well using plain CGI/Perl technology. However, there are web sites that require more power either because they are heavily hit, or because they have special performance requirements. Fortunately, Perl acceleration technology has matured in the last couple of years. Also fortunately, the eXtropia applications have been architected to take advantage of this.

We will talk primarily about acceleration of our applications under the Apache/mod_perl environment. However, the tips we discuss here can work just as well with other Perl accelerators such as Velocigen from Binary Evolution and PerlEx from ActiveState.

We talk about these accelerators in more detail in the eXtropia Application Development Toolkit Guide discussed in the Further References appendix. In addition, we encourage you to visit the website at http://perl.apache.org/ that includes links to documentation about mod_perl including the incredibly useful Mod_Perl Guide by Stas Bekman.

However, to refresh your memory here is a summary. Perl accelerators run CGI/Perl faster in two ways.

First, the Perl engine itself runs alongside the web server and remains in memory even after a request has been processed. Traditional CGI/Perl always requires loading the Perl engine from scratch each time a script is executed.

Second, because the Perl engine is persistent in memory, all code that is loaded is cached along with any global data that the scripts set.

Fortunately, all the applications in this book use Perl packages and are written using the object-oriented paradigm. This means that all the object libraries are highly modular and benefit quite a bit from being cached inside a Perl interpreter. In fact, if you were to run an eXtropia application using a mod_perl environment, you should expect dramatic speed increases.

However, we can go one step further. If you are using mod_perl, we suggest that you pre-load a lot of the modules including the application modules into the web server. For your reference here is a list of use statements indicating some of the commonly used modules you would want to load for the WebResponder.

use eXtropia::App::WebResponder; use eXtropia::Base; use eXtropia::Error; use eXtropia::View; use eXtropia::RecordSet; use eXtropia::DataSource::File; use eXtropia::Lock::File; use eXtropia::Session::File; use eXtropia::SessionManager::FormVar; use eXtropia::AuthManager::CGI; use eXtropia::Auth::DataSource; use eXtropia::Auth::Cache::Session; use eXtropia::UniqueFile; use eXtropia::KeyGenerator::POSIX; use eXtropia::KeyGenerator::Random; use eXtropia::Log::File; use eXtropia::DataHandlerManager::CGI; use eXtropia::DataHandler::Exists; use eXtropia::DataHandler::Email; use eXtropia::DataHandler::Number;

You may want to also consider preloading non-eXtropia modules that the eXtropia modules may depend on. Here is a small list:

use CGI; use CGI::Carp; use MD5; use Fcntl; use Date::Parse use Date::Manip

Preloading modules serves two purposes.

First, all the preloaded modules will be pre-cached so that they don't have to be loaded when the user first runs the script. Second, when Apache loads a module at startup, the module gets copied into every subsequently launched apache process. Thus, instead of executing a use statement in every apache process, you end up executing the use statement in the startup Apache process and then it gets copied in memory to all the subsequently launched apache processes for next to free.

In addition, most modern UNIX-based web servers share the RAM that was allocated in the first process. Therefore, if a module is loaded in the first process, the subsequent copies will share the same RAM. If the module loads after the Apache process is forked off, then the new forked copy will not share the same RAM for that module. [ TOC ]

[ TOC ]