In StatisticsVariableWillNotStayShared it became clear that ModPerl shouldn't be enabled across all the programs in the bin directory.

So I adjusted the stanza that enabled it from the above to this:

<FilesMatch "^(view|edit|preview|save|attach|upload|rename|installpasswd)$">
  SetHandler perl-script
  PerlHandler Apache::Registry
  Options ExecCGI
  PerlSendHeader On
</FilesMatch>

So instead of punting (with "*") I explicitly tell apache to optimise those specific scripts.

Thoughts?

-- DrewCard - 27 Jul 2002

Good idea to do this selectively - IMO the criteria for inclusion should be that they are 'transactional', meaning relatively quick-running. Hence, changes, rdiff, and statistics don't qualify, but most others should. So I think the following should be added:

• register
• viewfile - can be transactional for small attachments such as images
• manage
• passwd

-- RichardDonkin - 27 Jul 2002

I would think that all pieces should be allowed, both those items that are ran often and those that take time to run.

Are the long running tools running long because they rely on system calls?

Based on the above the stanza would look like...

<FilesMatch "^(view|viewfile|edit|preview|save|attach|upload|rename|installpasswd|passwd|manage)$">
  SetHandler perl-script
  PerlHandler Apache::Registry
  Options ExecCGI
  PerlSendHeader On
</FilesMatch>

-- DrewCard - 05 Aug 2002

I think the point of using mod_perl is to speed up CGI programs by cutting out the startup overhead. If the program is running for many seconds, the startup overhead of using CGI is minimal, so it's best just to run it as a CGI. Also, a mod_perl Apache process is expensive in terms of memory, and I think such processes take longer to create (more memory to allocate, possible paging, etc) - so if you consume a mod_perl process for tens of seconds, there's a much higher chance that you need to create a new process, slowing things down.

On the other hand, if there is enough memory in the system and enough mod_perl processes, it may be more efficient just to use mod_perl, rather than fork/exec a new Perl interpreter process and loading all the required modules.

On balance, I think it is more efficient on a loaded system to only use mod_perl for short-running programs, allowing the longer ones to use normal CGI - but perhaps a mod_perl expert would like to chip in?

-- RichardDonkin - 05 Aug 2002

I have TWiki set up in a shared hosting environment. I don't want my data files and directories to be writable by the "web" user, so I use ModPerl only for the read-only scripts (view, changes, etc.), and let the write scripts (edit, upload, rename, etc.) run as CGI under my account. This speeds up browsing quite a bit, and while the editing is still a little slow, it's a reasonable compromise.

One concern I have is that the web server is not configured to enable TaintChecking for ModPerl. Should I be worried?

-- KristopherJohnson - 15 Aug 2002

Something of a late reply - yes, you should really enable TaintChecking, although if you don't make any local changes it's not such a big deal. Taint checking is mainly to help developers put in the right checks but is good practice in any case, since software is inevitably upgraded and could have taint-checking issues as a result.

-- RichardDonkin - 15 Sep 2002

Is there a definitive statement on what the recommended configuration is? There seems to be several classes of files in twiki/bin:

• Ones that should only be run from the command-line (e.g. installpasswd)
• Ones that should probably not be run with mod_perl (e.g. statistics)
• ones that should be run with mod_perl (e.g. view)

• Doesn't require authentication (e.g. view)
• Requires authentication (e.g. edit)

Here is what I have, no idea if it is entirely correct or not (I'm using my own version of mod_auth_pam for authentication).

<Directory />
        AllowOverride   None
        Order           Allow,Deny
        Deny from       All
</Directory>

Alias /twiki/ /path/to/my/twiki/

<Directory /path/to/my/twiki/pub>
        Order           Deny,Allow
        Allow from      All
</Directory>

<Directory /path/to/my/twiki/bin>
        <FilesMatch "^(statistics|testenv)$">
                Options         +ExecCGI
                SetHandler      cgi-script
                Order           Deny,Allow
                Deny from       All
        </FilesMatch>
        <FilesMatch "^(changes|oops|rdiff|register|search|view|viewfile)$">
                Order           Deny,Allow
                Allow from      All
                Options         +ExecCGI
                SetHandler      perl-script
                PerlHandler     Apache::Registry
                PerlSendHeader  On
        </FilesMatch>
        <FilesMatch "^(attach|delete|edit|manage|preview|rename|save|upload)$">
                AuthType        Basic
                AuthName        "My TWiki"
                Require         valid-user
                ErrorDocument   401 \
                    /twiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth
                Order           Deny,Allow
                Allow from      All
                Options         +ExecCGI
                SetHandler      perl-script
                PerlHandler     Apache::Registry
                PerlSendHeader  On
        </FilesMatch>
</Directory>

Note: The above setup fails for setups that use regular htpasswd-based Authentication. Find the AuthUserFile line in your .htaccess from /twiki/bin/ and put that line after AuthType. e.g.:

...
                AuthType        Basic
                AuthUserFile /path/to/twiki/data/.htpasswd
                AuthName        "My TWiki"
...

-- AsheeshLaroia - 08 Jul 2003

I'd suggest adding upload to the exclusions; it can take quite some time to upload a file, and this seems to cause mod_perl to time-out, the symptom of which is a 'document contains no data' error.

-- EllisPritchard - 18 Aug 2005

Under apache2 with mod_perl 1 this is what was required for me

           Options +ExecCGI 
           SetHandler perl-script
           PerlResponseHandler ModPerl::Registry

           #May or may not be necessary, I couldn't be bothered to check
           #Parses output for Headers, and moves the to the header I guess
           PerlOptions +ParseHeaders

-- JamesWestby - 28 Mar 2006

I agree we need a definitive list of those that can and cannot be accelerated, for ModPerl, FastCGI and PersistentPerl (SpeedyCGI).

-- MartinCleaver - 01 May 2006