Combining Apache and Perl
The CGI (Common Gateway Interface) standard has been around for several years and is beginning to show its age. CGI is great because all web servers support it, programmers can write in any language, and programs can be portable across a large number of platforms. Netscape's NSAPI and Microsoft's ISAPI bind more tightly to their respective web servers, but programmers interested in using these APIs are much more restricted than with CGI.
A particularly big problem with CGI is its inefficiency. Each invocation of a CGI program creates a new process on the server. If you write CGI programs in Perl, you are starting a new copy of Perl each time a CGI program runs, using additional memory and processor time. Wouldn't it be nice if we could have the flexibility of CGI programs without having to use all of those system resources? Better yet, wouldn't it be great if we could use our existing CGI programs in such a framework with little or no modification? The answer, of course, is “yes”; even as hardware continues to get cheaper and more powerful, it seems silly to be wasting memory and CPU time unnecessarily.
This month, we look at mod_perl--one of the proposed solutions to this problem. mod_perl is a module for the popular and powerful Apache web server, which runs on many operating systems including Linux. At the most basic level, mod_perl makes it possible to run server-side Perl programs more efficiently than when using the CGI protocol. However, mod_perl offers much more than efficiency, as we will see. It also provides a full interface to the Apache internals, giving Perl programmers a chance to modify the web server itself.
Apache modules are configured and installed at compile time. If you are interested in installing mod_perl, you have to download and recompile the source code in Apache. Luckily, this is rather easy to do. Note that while anyone can download, configure and compile Apache, only someone with root access can install Apache to its default position. If you don't have root access, you will still be able to run, but only on an unrestricted port number, namely, one above 1024.
The latest version of mod_perl is always available from CPAN (Comprehensive Perl Archive Network). At this time, the latest version of mod_perl is 1.10, which means that you can retrieve it from http://www.perl.com/CPAN/modules/by-module/Apache/mod_perl-1.10.tar.gz. Later versions will have the same URL, with a different version number. In addition, try to use a CPAN mirror close to you, rather than loading down www.perl.com; go to http://www.perl.com/CPAN/ for help in finding one.
Once you have downloaded mod_perl, you will also have to download the latest version of Apache, 1.2.6, from http://www.apache.org/ or one of its mirrors. Unpack the Apache and mod_perl distributions in the same directory. On my system, I did the following:
cd /downloads tar -zxvf apache_1.2.6.tar.gz tar -zxvf mod_perl-1.10.tar.gz
If you want to modify the default Apache module set, now is the time to modify /src/Configuration. If you are not familiar with Apache configuration, don't worry—things will work just fine without customizing the module set.
The rest of the Apache configuration and compilation is done within the mod_perl directory. Move into the mod_perl directory (probably called something like mod_perl-1.10) and type:
On my system, mod_perl asks me two questions:
Configure mod_perl with ../apache_1.2.6/src ? [y]to which I press return, and
Shall I build httpd in ../apache_1.2.6/src for you? [y]to which I press return again. This configures all of the files necessary for building mod_perl and Apache. When the UNIX shell prompt returns, simply type make and press return. The resulting Apache binary (httpd) will be in the src subdirectory under the Apache directory. On my system, httpd resides in /usr/sbin/httpd, so copying the resulting binary will replace the old Apache with the new one.
Restart Apache by logging in as root and typing:
killall -1 -v httpd
Now, you're in business with your new version of Apache. If you're not sure whether the new version has been installed, connect to the web server and ask for its version information:
telnet localhost 80After connecting, type:
HEAD / HTTP/1.0On my system, I get the following response:
HTTP/1.1 200 OK Date: Sun, 12 Apr 1998 19:02:41 GMT Server: Apache/1.2.6 mod_perl/1.10 Connection: close Content-Type: text/htmlIn other words, the web server running on port 80 (the default port for HTTP traffic) is running Apache 1.2.6, with mod_perl 1.10 compiled in.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?