Someone recently contacted me with an interesting problem. His company is building a Web-based application using Microsoft Windows NT and Internet Information Server (IIS). The team is using Borland International's Delphi to hook into Internet Server API, or ISAPI, for IIS.
The problem that he's experiencing is simple. IIS is crashing, even under light loads. And the problem doesn't seem to be with the Delphi code. So he wanted to know if another Web server, such as Netscape Communication's Enterprise Server, would be better able to handle the task.
This is actually a fairly common problem. And in most cases, the question shouldn't revolve around which Web server to use, but whether or not it is appropriate to use a Web-server API when a CGI script or program would do.
I'd like to give Microsoft and Netscape the benefit of the doubt, but it seems to me that neither ISAPI nor Netscape Server API (NSAPI) have much to do with serving a customer's needs.
These companies recommend their respective APIs for their performance gains over CGI programs. A program that taps into the Web server API gets loaded only once, along with the server. CGI programs are loaded repeatedly, on demand.
But it is more likely that these companies encourage you to use their server APIs in order to make it difficult for you to switch from one type of server to another. Programs that use ISAPI will not run with NSAPI and vice versa. CGI programs, on the other hand, are instantly portable across Web servers because they run outside of the Web server's environment.
The performance gain using either API instead of a CGI approach is negligible. And you pay a high price for that benefit, as this fellow, along with many others, is discovering.
You see, any program using ISAPI or NSAPI becomes part of the Web server. If there are memory leaks or other bugs in your program, then the entire Web server inherits those memory leaks and bugs. Even if you start with a stable Web server, your program can make it unstable.
If that isn't bad enough, consider that it is unlikely any Web server is problem-free. It probably has undetected memory leaks and bugs of its own. So it is possible for your program to be the catalyst that causes those hidden bugs to surface. Finding and squashing such bugs could prove almost impossible. You will be focusing on debugging your own code, but your code might be flawless and only aggravating an existing situation.
Worst of all, the ill effects of bugs, such as memory leaks, tend to accumulate and surface only after some time and according to certain circumstances. That means you will have to do extensive regression testing to find them in the first place.
When you use CGI, the program is loaded, used, and then discarded. If a CGI program has a bug, it is much less likely to bring the Web server down because it executes in its own separate program space. Even if a CGI program occasionally crashes, the Web server should continue to hum along on its own.
API-based programs are also much more difficult to maintain. Assume you've done the regression testing on your program and have deployed your Web-server application. Two months down the road, Josette in customer service rings you up and complains that the data-entry form on such-and-such page doesn't give her enough space to type her entire e-mail address. So you expand that field.
Suddenly, the server starts to crash daily. Why? Either your fix to the e-mail address field created a new problem or it caused a latent problem to surface. Either way, the only way to avoid this side-effect is to do extensive regression testing. It is far easier (and safer) to make the change to an external CGI program and debug it outside of the Web-server environment, where there are fewer variables to worry about.
So far, I've never heard of a case in which the tiny savings in performance was worth the use of direct API calls. If you learned this lesson the hard way or if you're an exception, I'd like to hear from you.
Former consultant and programmer, Nicholas Petreley is editor in chief at NC World (http://www.ncworldmag.com). Reach him at nicholas_petreley@infoworld.com or join his forum on InfoWorld Electric (http://www.infoworld.com).