Apache::Registry caches the script in the package whose name is constructed from the URI from which the script is accessed. If the same script can be reached by different URIs, which is possible if you have used symbolic links or aliases, the same script will be stored in memory more than once, which is a waste.

For example, assuming that you already have the script at /home/httpd/perl/news/news.pl, you can create a symbolic link:

panic% ln -s /home/httpd/perl/news/news.pl /home/httpd/perl/news.pl

Now the script can be reached through both URIs, /news/news.pl and /news.pl. This doesn't really matter until the two URIs get advertised and users reach the same script from the two of them.

Now start the server in single-server mode and issue a request to both URIs:


To reveal the duplication, you should use the Apache::Status module. Among other things, it shows all the compiled Apache::Registryscripts (using their respective packages). If you are using the default configuration directives, you should either use this URI:


or just go to the main menu at:


and click on the "Compiled Registry Scripts" menu item.

If the script was accessed through the two URIs, you will see the output shown in Figure 6-1.

Figure 6-1

Figure 6-1. Compiled Registry Scripts output

You can usually spot this kind of problem by running a link checker that goes recursively through all the pages of the service by following all links, and then using Apache::Status to find the symlink duplicates (without restarting the server, of course). To make it easier to figure out what to look for, first find all symbolic links. For example, in our case, the following command shows that we have only one symlink:

panic% find /home/httpd/perl -type l

So now we can look for that symlink in the output of the Compiled Registry Scripts section.

Notice that if you perform the testing in multi-server mode, some child processes might show only one entry or none at all, since they might not serve the same requests as the others.