It should look the same as the regular perl script.
What is different is that there is a persistent process involved.
To get an idea of what's going on do this:
$ ps ax | grep speedy_backend
You should see a representation of the script as a process.
Benchmark comparison
Compare the speedy performance with regular perl/CGI performance
using the Apache Benchmark software tool, ab.
For comparison sake, it's best to run each command in separate
shells (not concurrently):
$ ab -n 2000 -c 100 http://localhost/~rkline/perl-cgi/printenv.cgi
versus:
$ ab -n 2000 -c 100 http://localhost/~rkline/perl-cgi/printenv-speedy.cgi
This is creating 2000 request with a concurrency level of 100 connections.
You'll notice that the latter is faster and the statistics bear
this out. Look at the number for:
Time per request: ______ [ms] (mean, across all concurrent requests)
A discussion of the ab tool and other benchmarking tools
can be found at this URL:
$ ab -n 2000 -c 100 http://localhost/~rkline/perl-cgi/printenv-speedy.speedy
You'll see that this is significantly faster than either of the previous two
versions. The main issue with this approach is there does not appear to be any
way (at least, any easy way) to make this last version work in suexec mode.
Compressed JavaScript
One of the downsides of client-side (i.e., JavaScript)
toolkits
like jQuery is that browsers must download a significant
amount of JavaScript code in order to use them.
From the jQuery website, the JavaScript file is
presented in two forms minified and uncompressed,
e.g.:
The minified form has exactly the same code, except that
almost every possible
whitespace character is removed, leaving it essentially unreadable.
The reason the minified version is better to use is that, obviously,
that it requires less bandwidth than the compressed version.
Even better is using an actual compression. It turns
out that you usually can use gzip-based compression.
A browser request will send to the server its capabilites in
the HTTP request header, and in this
header, indicate whether it can receive and process
gzipped content.
To see what a browser sends, install the Live HTTP headers plugin
in Firefox by going to:
Tools Add-ons Get Add-ons
Enter "http headers" in the search box to bring up Live HTTP headers.
Then install it, restart Firefox, and bring up
Tools Live HTTP headers from the menu.
Assuming you have jQuery installed as indicated in the
previous documents, active this URL:
The key client information is the gzip value within the
in the Accept-Encoding key which
indicates that the browser accepts gzip compression.
We can see how much bandwidth we'll save
by counting the number of bytes in the compressed form:
It should come out to around 19K bytes, one third of the
minimified version and one sixth of the uncompressed version.
There appear to be a wide variety of ways to have
the Apache server do the compression, but I've found this Php-based
way to be simple and successful (it can even be used
if you don't have root access).
Edit the file
/etc/apache2/conf.d/aliases.conf
and add this to the end:
The Lighttpd (pron. lighty) HTTP server is an alternative
to Apache. It claims to be designed for high performance. The
home and documentation pages are these:
The server will fail to start because of the port conflict
with Apache on port 80. We want to run it as an alternative
on port 81, so edit
/etc/lighttpd/lighttpd.conf
and look for the line which defines server.port and set it:
## bind to port (default: 80)
server.port = 81
Also, enable the necessary modules while we're at it.
We'll soon configure the CGI module.
As in the case of Apache, we must do some configuration steps to get
Lighttpd to work on Php and Perl/CGI scripts.
Setting up Perl/CGI is easy; however,
creating suexec capabilities is difficult, poorly documented, etc.
You have to use the Apache suexec executable,
/usr/lib/apache2/suexec, explicitly.
which is also
difficult due to the poor documentation and strong usage restrictions.
The way it works out (for me)
most easily is that a each user who wants to
run CGI scripts in suexec mode must own a directory
within in the server's document root. The directory we create
for the user, although it could be named otherwise, uses their
login name.
Here is how to proceed. You need two executables, one owned by
root in a common location and the other in the special directory
in the document root.
Create a directory named by your login owned by you within the document
root, /var/www. The easiest way is:
$ mkdir LOGIN
$ sudo mv LOGIN /var/www
Next, download the support files and run the installation script:
With exception of the ".speedy" scripts and wordpress,
you should be able to run
every web application simply by adding the ":81" port designation.
The fastcgi module in Lighttpd automatically builds in support for Php/CGI,
which it claims to be faster than using the Apache Php module.
Here are some tests:
Add-ons