SpeedyCGI (also known as PersistentPerl) is an Apache module (Unix/Linux only) that can be used to accelerate CGI perl scripts. See http://daemoninc.com/SpeedyCGI/ (or CPAN) and see also ModPerl and FastCGI.

TO DO: Could someone refactor this page, combining somehow with PersistentPerl, rather than having two discussions on the same tool? --RD

Convert a perl CGI script to SpeedyCGI by switching the executable name from /usr/mumble/perl to /usr/mumble/speedy. It should be, for the most part, that easy. But be aware that globals are persistant over different invocations of the same script, so your perl had better be well behaved.

Contributors comments

-- NicholasLee - 17 Sep 2000
-- StanleyKnutson - 27 Nov 2000
-- PeterNixon - 18 Dec 2001

Installing SpeedyCGI is a bit painful at least on my webhost, but doable, and much easier than trying to find a webhost that supports ModPerl of course.

-- RichardDonkin - 03 Aug 2002
I tried to set up multiple TWikis instances on the same machine & server (on different URLs, with virtual hosts), and mod_perl didnt work (pages get totally mixed between the two sites). By browsing the web , I saw that many solution existed, but that only SpeedyCGI could provide me with what I wanted: Guaranteed separation of the data loaded for the different TWiki running. I discovered, moreover, that now SpeedyCGI has even an apache module, mod_speedycgi that makes installation a breeze on apache:

• Install mod_speedycgi on your apache (your linux distrib should have it already)
• in httpd.conf, add the line (path may vary):

       LoadModule speedycgi_module /usr/lib/apache/1.3/mod_speedycgi.so

• Then, in the .htaccess on the bin/ dir, add:

PerlSendHeader On   
SetHandler  speedycgi-script
SpeedyTimeout 600
Group MYWIKI
Options +ExecCGI

... And that's all, not need to change the headers of the scripts in bin/ !

Note: the Group directive may not yet exist on your version of mod_speedycgi. It allows to separate the scripts in differing perl interpreters so that their data cannot mix. You will want to have a different group name for each TWiki installation on the server. If it gives a syntax error, just comment it, as it is the case currently on the Debian stable (woody).

I am running now 2 TWikis on the same apache, one in mod_perl, the other in mod_speedycgi, without problems, and the speed of the two seem similar (within 5%).

More info: http://daemoninc.com/SpeedyCGI/, http://aio4u.com/doc/libapache-mod-speedycgi/ (not accessible), http://yapc.org/America/previous-years/2001/proceedings/horrocks.speedycgi.pdf, http://webreference.com/new/speedycgi2.html

-- ColasNahaboo - 09 Aug 2003

There are known problems with SmartSessionPlugin (some versions?)

The problems with SmartSessionPlugin and SpeedyCGI have much (everything?) to do with the bug discussed in InitializeUserHandlerBroken.

A hack discussed at SmartSessionPlugin will allow SmartSessionPlugin to work with SpeedyCGI, but ultimately the fix to InitializeUserHandlerBroken will provide the cleanest fix to these problems.

I anticipate that the problem with SmartSessionPlugin and SpeedyCGI have now been fixed as of version 2.122 of SmartSessionPlugin where a hack was added to change how and where initialization occurs.

-- TedPavlic - 03 Sep 2003

-- CrawfordCurrie - 11 Jun 2004

Think about tuning speedycgi - it is better if you have a rather small maschine; by default, it forks as many backends as possible.

.htaccess entry is like

• SpeedyTimeOut 600

-- MartinSteldinger - 05 Aug 2004

We are using SpeedyCGI in Cairo together with SmartSessionPlugin at our site without any problems sofar. Only thing we encountered was problems with Plugins.TopicVarsPlugin which made some searches, WebChanges and various plugins behave erratically. Disabling TopicVarsPlugin helped us immediately.

-- SteffenPoulsen - 19 Sep 2004

This may be a stupid question, but please bear with me: We are using LDAP authentication in our apache, so the .htaccess file is not used. I would like to leverage the trick identified by ColasNahaboo to avoid changing the shebangs in all the twiki scripts. Would it work if I put the above changes in my .htaccess file, but nothing else? Or can above go somewhere in httpd.conf?

-- ThomasWeigert - 20 Sep 2004

What you can do in .htaccess is defined by the AllowOverrides directive in httpd.conf that applies to the bin dir. Read http://httpd.apache.org/docs/mod/core.html#allowoverride If it is set to AllowOverride None then (and only then) are you "not using .htaccess ". Anything that can go in .htaccess can also go in httpd.conf, in the <Directory> statement for twiki/bin.

FYI I only use speedy on the view script. This is the most frequently access script, by a big margin, and the one most people would agree has to be the fastest. It's not a big burden to change the shebang line at the head of this one script.

-- CrawfordCurrie - 20 Sep 2004

Hm. I tried SpeedyCGI 2.22 on my Red Hat 8.0 system (apache 2.0.40). I built and installed SpeedyCGI myself. I tried to use the apache module. For a while it seemed to work fine. Then I got a report from one of my users that when he clicked the Cancel button in an editing page he got:

Server error!
    The server encountered an internal error and was unable to complete your request. 
    Error message:
    Premature end of script headers: view 
    If you think this is a server error, please contact the webmaster 

Then he couldn't see the page anymore. Then it worked. Then it stopped working. Bizarre stuff.

I disabled the module and instead edited the bin/view script to use /usr/bin/speedy instead of /usr/bin/perl. So far, so good (fingers crossed).

Any thoughts? I wonder if I should be using the -g option in my bin/view script?

-- PaulSmith - 29 Apr 2005

Note: some plugins currently clash with SpeedyCGI: apparently SectionalEditPlugin and MultiEditPlugin cache things that then cause trouble (multiple renders) when page is saved and viewed. Just a heads-up for anyone having this sort of problem. (Anyone feel free to delete this entry if/when this is resolved.)

-- MarcusLeonard - 01 May 2005

Marcus, in another topic you mentioned that you are obtaining 20% performance improvements using SpeedyCGI. Do you use SpeedyCGI across all scripts, or just on a few selected scripts? How do you invoke SpeedyCGI (i.e., did you change the shebang line in all the scripts, or do you do it through the apache conf module? It would be great if you could provide some instructions.

When I installed SpeedyCGI a while ago, I could see no performance improvement (on Beijing).

-- ThomasWeigert - 01 May 2005

It pays off to run view and viewauth under SpeedyCGI, and possibly rdiff. Other scripts are not that critical since a cgi accelerator is useful to accelerate slow topics (with dymanic content)

At work we use SpeedyCGI in a production environment. I have seen page access time almost cut in half.

One implication of SpeedyCGI: You need to touch the scripts each time you make a change to one of TWiki's Perl modules. This makes the scripts recompile on next run.

-- PeterThoeny - 01 May 2005

I couldn't be bothered with the apache module since the build I found was too old for my apache binary, so I just installed Speedy (an RPM from the Dries Fedora/Red Hat repository) and changed the shebang line at the start of the view script (#!/usr/bin/speedy -wT -- -t600). Didn't think of rdiff - good idea, Peter. I like providing features to our many non-technical users, so I tend to install quite a few plugins. Some slow things down a bit, so Speedy would be good to bring some speed back - not that it's running that slow yet at my workplace (without Speedy). At home on my old Athlon 1000, using ab to benchmark apache, I saw 4-5 second times go down to 2-3.

-- MarcusLeonard - 02 May 2005

Has anyone had success installing SpeedyCGI on a hosted domain (e.g. Dreamhost)? I tried today but without success. I couldn't get it to compile correctly without access to root.

-- LynnwoodBrown - 24 Aug 2005

Never tried without root, TBH. Can't you do what Marcus did, and install a binary?

A couple of things to watch out for; by default, it doesn't limit the resources it grabs. You should put sensible limits on things like the number of processes it creates, and the lifetimes of those processes.

-- CrawfordCurrie - 24 Aug 2005

I'm finding that SpeedyCGI is breaking the search functionality on my installation of TWikiRelease04x00x01. (It worked just fine with my installation of TWikiRelease04Sep2004, which I recently upgraded.) I'm using SpeedyCGI in the shebang of my view script. When I remove it, search works fine.

Anyone else found the same problem? Any workarounds?

-- JamesAnderson - 13 Feb 2006

What is the symptom, James? (I have no apparent problems with search and SpeedyCGI here).

-- SteffenPoulsen - 13 Feb 2006

Sorry, Steffen, I should have specified that the search always returns with no results (for all webs).

But I think I've found out what was wrong. I had to use configure to change the paths to egrep and fgrep (to point to GNU versions). Yet for some reason, my SpeedyCGI-enhanced view didn't pick up the new config settings. I restored the original shebang on my view script, ran a search, and it worked fine (search results as expected). I then put SpeedyCGI back in the shebang and ran the search again. Bingo -- search now seems to work fine.

Presumably it was a caching problem. But it seems that whenever I change the config, I have to go through the process above in order for SpeedyCGI to catch up with the new config settings.

Anyway, I hope that recording my experiences here may be helpful to others who are encountering similar weirdness with SpeedyCGI and TWikiRelease04x00x01 configuration.

-- JamesAnderson - 13 Feb 2006

Okay, now I understand what was going on. The scripts need to be recompiled in order for the new config settings to take effect. And as PeterThoeny noted above: "You need to touch the scripts each time you make a change to one of TWiki's Perl modules. This makes the scripts recompile on next run."

-- JamesAnderson - 13 Feb 2006

The speedycgi_backend processes need a lot (!!) of memory, so I added the #!/usr/bin/speedy only to the view script and restricted it further to use only two processes and to reload after every second execution. The shebang looks now like #!/usr/bin/speedy -wT -- -r2 -M2 and made my 64 MB RAM 233 PII IBM ThinkPad Webserver fly (which means running acceptable fast enough).

-- TobiasRoeser - 25 Feb 2006

SpeedyCGI's new name is PersistentPerl

from http://daemoninc.com/PersistentPerl/, "SpeedyCGI was the original name, but because people weren't sure what it did, the name PersistentPerl was picked as an alias. At some point SpeedyCGI will be replaced by PersistentPerl, or become a sub-class of PersistentPerl to avoid always having two distributions."

-- WillNorris - 27 Feb 2006

I've been trying PersistentPerl on a Lycos Virtual Dedicated Server, both by editing the #! line in the view script, and by using the mod_persistentperl2.c apache module. On this host, I needed to patch PersistentPerl to get it to work, and I guess that this patch would be needed on any system running under Linux-VServer, not just Lycos'.

Once working, the speedup was certainly useful. I have the most basic server that Lycos offer (128Mb of memory), and viewing pages on TWiki was agonisingly slow before.

The underlying problem is with V-Server. I may try to get a bug report in, but if anyone wants the details of what I did to PersistentPerl to get it working, please let me know.

-- PeterKeller - 16 Mar 2006

A little further investigation shows that the fastest setup is using Apache2 with the worker MPM and a #! line in bin/view like this: #!/home/twiki/bin/perperl -wT -- -M3 -r10 (inspired by TobiasRoeser's comments above). Using the Apache module requires the prefork MPM (apt-get install apache2-mpm-prefork on Debian Sarge) and is a lot slower, although still faster than not using PersistentPerl at all

-- PeterKeller - 17 Mar 2006

Before SpeedyCGI (pperl 2.2):

[wikihoster@host DEVELOP]$ /usr/sbin/ab -n 50 -c 3 http://www.servername.com/twiki/bin/view
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.cleaver.org (be patient).....done
Server Software:        Apache/1.3.34
Server Port:            80

Document Path:          /twiki/bin/view
Document Length:        19839 bytes

Concurrency Level:      3
Time taken for tests:   121.654 seconds
Complete requests:      50
Failed requests:        0
Broken pipe errors:     0
Total transferred:      1006850 bytes
HTML transferred:       991950 bytes
Requests per second:    0.41 [#/sec] (mean)
Time per request:       7299.24 [ms] (mean)
Time per request:       2433.08 [ms] (mean, across all concurrent requests)
Transfer rate:          8.28 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.0      0     0
Processing:  4357  7225 2686.9   6053 14320
Waiting:     4357  7225 2686.9   6053 14320
Total:       4357  7225 2686.9   6053 14320

Percentage of the requests served within a certain time (ms)
  50%   6053
  66%   8000
  75%   8808
  80%   9600
  90%  12229
  95%  12760
  98%  13366
  99%  14320
 100%  14320 (last request)

[wikihoster@host DEVELOP]$ /usr/sbin/ab -n 50 -c 3 http://www.servername.com/twiki/bin/view.perperl
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.cleaver.org (be patient).....done
Server Software:        Apache/1.3.34
Server Port:            80

Document Path:          /twiki/bin/view.perperl
Document Length:        19839 bytes

Concurrency Level:      3
Time taken for tests:   66.211 seconds
Complete requests:      50
Failed requests:        0
Broken pipe errors:     0
Total transferred:      1006850 bytes
HTML transferred:       991950 bytes
Requests per second:    0.76 [#/sec] (mean)
Time per request:       3972.66 [ms] (mean)
Time per request:       1324.22 [ms] (mean, across all concurrent requests)
Transfer rate:          15.21 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.0      0     0
Processing:  1902  3933 2287.9   2902 10406
Waiting:     1902  3933 2287.9   2902 10406
Total:       1902  3933 2287.9   2902 10406

Percentage of the requests served within a certain time (ms)
  50%   2902
  66%   3529
  75%   4593
  80%   5335
  90%   8158
  95%   9181
  98%  10278
  99%  10406
 100%  10406 (last request)

As the total time for the requests has dropped from

Time taken for tests: 121.654 seconds

to

Time taken for tests: 66.211 seconds

I conclude that it was worth the effort.

---

I had to recompile peristentperl 2.2 as installing the rpm resulted in a version that worked ok for the test script supplied in the PersistentPerl help but not for Twiki-4's view script.

-- MartinCleaver - 23 Mar 2006

I've had no reply from the author of PersistentPerl about the problems I described above, so here is a description of the problem that I had and the solution that I found. First, create a file with some trivial perl code, e.g.:

print "Hello world\n";

Note that you have to do this with a file: using perperl -e may just segfault.

Attempt to run the file using PersistentPerl:

/usr/bin/perperl pptest.pl

If you have the same problem that I had, you will get output like:

perperl[24181]: temp file is corrupt

To fix this specific problem, find the file src/perperl_file.c in the distribution. Look for the function:

   static void file_unlock(void) {
       struct flock fl;

and find the line:

FILE_HEAD.lock_owner = 0;

Add the following line immediately after:

if ( msync( &(FILE_HEAD), sizeof(file_head_t), MS_SYNC|MS_INVALIDATE ) ) perperl_util_die("msync failed");

Rebuild, and check that the test produces the correct result.

Please note that I only did this to get the TWiki view script to work. It may well be that the msync is required in other places as well to get PersistentPerl to work correctly when changes are being made to the TWiki data files.

Also, I was wrong where I said above that the problem was with Linux-VServer. On a more careful reading of the mmap(2) man page I found:

       MAP_SHARED Share  this  mapping  with all other processes that map this object.  Storing to the region is
                  equivalent to writing to the file.  The file may not actually be  updated  until  msync(2)  or
                  munmap(2) are called.
       ...
       You must specify exactly one of MAP_SHARED and MAP_PRIVATE.

       The above three flags are described in POSIX.1b (formerly POSIX.4) and SUSv2.

msync should be called after any change to the memory-mapped file that needs to be read back before the file is munmap-ed, so PersistentPerl needs some more extensive patching to guarantee correct behaviour (at least on systems where the behaviour of the MAP_SHARED flag is as describe above).

-- PeterKeller - 04 Apr 2006

Commenting is disabled while not logged in