Apache Week
   
   Issue 208, 21st July 2000:  

Copyright ©2020 Red Hat, Inc

In this issue


Apache Week had the pleasure of visiting Monterey in July to report on the 4th O'Reilly Open Source Software Convention. This seemed like the ideal assignment; we get to fly to California in July, avoiding the British weather, and spend a week right on the West Coast just a few hours south of the Bay Area. That was the plan, but the reality started to kick in on our drive down the coast on Sunday to the conference centre when it was cold, windy, and raining. The conference was being held in the Monterey conference centre, an impressive building joined to two hotels. We knew instantly that we had the right building as whilst registering we were approached by a fellow attendee who explained how he had worked out spoofing the Internet hotel connections to avoid paying for them.

7.45am on Monday morning is not my most favourite time of the week, and it didn't help that we were greeted with the sight of over a thousand tutorial delegates jostling for seats to eat the provided breakfast. The first two days of the conference were dedicated to longer tutorial sessions, each one scheduled for 3.5 hours allowing the presenters to really get into the depths of their chosen subject. With 13 simultaneous tutorial sessions on the first day, and only two Apache Week staff, we found it really hard to choose between them. Other delegates we spoke to were similarly overwhelmed by the choice.

Getting started with mod_perl

I've personally been writing CGI scripts in Perl for many years, but when I needed something to run quickly switched to using a compiled language, usually C, instead. So I was interested in finding out about mod_perl and if it would make writing scripts in C redundant, or indeed if the advantages were outweighed by the disadvantages. Stas Bekman's presentation "Getting Started with mod_perl" seemed the ideal talk to find this out, although it did mean skipping the popular "Advanced Perl" and "Advanced CGI" tutorials which also looked interesting to Apache developers. By far the most popular tutorials were the ones on Perl, with nearly 250 delegates attending the all-day session on advanced object-orientated Perl.

Within a few minutes Stas had assured the 90 attendees that to start using mod_perl "doesn't take weeks or months" and that in under an hour using the Apache::Registry module you can get all your existing perl CGI scripts running without many changes, if any. We were told that the biggest advantage of using mod_perl is speed as Perl is pre-loaded into each Apache child process. This means there is no forking, required for CGI scripts, and real life experience has shown that this gives speedups of between 10 and 100 times over running Perl scripts under CGI.

Everything comes with a price, and the biggest disadvantage of using mod_perl is it makes the Apache child processes much larger; caused by the Perl interpreter being built into the server. However, since the requests will now be handled much quicker there should be fewer processes around, keeping the total memory usage down. Having mod_perl enabled processes dealing with static content is not particularly efficient though, and Stas explained that splitting servers so that you have a separate lightweight server running to handle static content was a good approach. The best efficiency can be obtained by running a reverse proxy server connect to a mod_perl enabled server and handle static content directly.

Performance issues with mod_perl were highlighted together with a series of action points to improve the user's browsing experience. These included the disabling of Keep Alives, tuning of the MaxClients directive, through to configuring the sharing of memory between processes.

Advanced mod_perl

As if a morning of mod_perl wasn't enough, I decided to subject myself to more from the "Advanced mod_perl" session from Doug MacEachern the same afternoon. Doug was the original author of mod_perl and co-author of the book "Writing Apache Modules with Perl and C," published by O'Reilly and Associates, with Lincoln Stein. The presentation ran through the API of mod_perl and was designed for more advanced mod_perl users.

At the end of the talk, Doug covered some of the issues relating to Apache 2.0. Apache 2.0 generally runs in a threaded environment, and this produces a whole new set of issues of thread safety not only of Apache but of Perl and mod_perl. mod_perl for Apache 2.0 will also need to be rewritten to follow any of the alterations made to Apache 2.0 to support filters.

Apache security

The same afternoon Lincoln Stein, well known for his work on Perl, spoke on a wide variety of subjects regarding running Apache in a secure manner. These included forms of security and security vulnerabilities such as retrieving unauthorised information, making malicious alterations to web sites, unauthorised alterations of configuration, relayed attacks, and denial of service attacks.

The tutorial was primarily directed towards those designing or administering web servers at an overview level. Instead of spending time detailing the specifics of how Apache internally manages security, Lincoln discussed issues as they apply to the deployment of services.


We took an early night on Monday in order to prepare for a long second day of tutorials, the Appaloosa awards, and the free beer at the after-conference parties.

Apache::ASP

Joshua Charmas kicked off the day with a talk on his ASP module for Apache with Perl. He dismissed the myth that Active Server Pages were all about Visual Basic Script and showed how his module was compatible with NT/IIS and PerlScript. One powerful feature of the module is the session tracking capabilities which can even work across multiple back-end machine and for users who have disabled cookies.

A detailed example was given of site built completely on the Apache::ASP module, using the session tracking, authentication, banner serving, and XML publishing ablilities.

Apache 2.0

Ryan Bloom gave a dynamic presentation about the future of Apache in his talk "Apache 2.0". He covered MPM and APR as previously explained in his Apache Week feature. APR is the Apache Portable Run-time, designed to be useful library for cross-platform development and in the future for more than just Apache. Ryan explained that he would like to see APR in use in other products that need to be completely cross-platform and even include functions such as popping up windows. Fortunately such functionality if ever added to APR would not be in use by Apache itself.

Ryan commented that Apache 2.0 had been fairly stable for some time and has been used by some sites with significant amounts of traffic, but that there are still rough edges and it still is not recommended to be used by production sites. One of these rough edges is the support for filtering, a feature that is currently being worked on and likely to be in the next alpha release.

There is no timescale fixed for the Apache 2.0 release, although there will be continued alpha and beta versions made available as work progresses.


New to the conference this year were the Appaloosa Awards, designed to reward the people and projects who have had a significant influence on Apache. The voting was open to Apache Week readers for one week and we received just under 3000 votes in total. The awards were announced on Tuesday evening at the conference by ASF member and Apache program co-chair Chuck Mercko.

The Vision Award was for the best ideas to move Apache forward and was won by Ryan Bloom for Apache 2.0 and Roy Fielding for standards and industry acceptance of Apache.

The Evangelism Award was for promoting Apache awareness or acceptance was won by Lars Eilebrecht, and collected by Dirk-Willem Van Guilik for the Apache XML Projects.

The Technical Contribution Award went to Doug McEachern for mod_perl and Rasmus Lerdorf collected on behalf of the PHP Group.

Next week...

In the next edition we will cover events of the last two days of the conference, when the main sessions, keynotes, and exhibition took place. We'll also dig out the photos we took, and will hopefully have recovered from the jetlag.