Slashdot Mirror


Using Single Apache SSL/Non-SSL in Production?

tck1000 asks: "I currently maintain some legacy webservers, running Apache 1.3.x on Linux, on x86 hardware. Two separate daemons are used. One to serve SSL vhosts, and one to server non-SSL vhosts. Each of these servers also is compiled with PHP, mod_perl, and JServe, and also works with a Tomcat servlet engines. In the process of planning an upgrade path, I've thought about using a single daemon to serve both the SSL and Non-SSL vhosts. Is this a good idea?"

"These webservers serve about 4 million hits a day across all the vhosts. I'm worried about memory usage if every httpd process has to load mod_ssl, as well as everything else they load.

I've been searching for comparisons between running 2 daemons (and the associated effort in maintaining/upgrading/patching), vs. running a single daemon (with any added overhead it entails).

I've found a lot of examples of how to do it, but not much on the why's.

Comments, Opinions, Ideas, Links?"

4 of 37 comments (clear)

  1. Might consider more than that... by iwadasn · · Score: 2, Interesting

    First of all, I am a bit of a web admin. I write software all day, run my own website on my machine, and many of my past jobs were writing asp (shudder) and cgi of various sorts.

    Basically I've always found that people get into trouble when they run webservers with excessive complexity. On a modern webserver, serving just about anything, the actual performance of the webserver software doesn't mean much, all the time is taken with DB interaction and custom code (cgi, jsp, etc..). I would therefore suggest that you try to simplify a bit.

    I've tried jboss and tomcat and don't have any complaints. They work very well, and (at least from what I've heard) are very secure. No buffer overflows to be found, for obvious reasons. In addition, the portabiliity is nice.

    Because of this you might consider trying to run tomcat without apache. The SSL in tomcat works fine, and it's easy enough to set it up so that it will serve both secure and non secure pages. This simplifies everything by placing the entire webserver (except for the cgi) in a single process. I've never really tried the cgi through tomcat, but I'm told it works so you might want to try it at some point. Not sure about PHP, and of course do a lot of testing and investigation before rolling this out into production (as if that even needed to be said).

    If this works for you, you've eliminated all the OS/architecturre dependencies at once. In addition it'll help by cutting out one piece of software (apache), and might help security.

  2. Re:Slashdot/Sourceforge/etc... by Graelin · · Score: 2, Interesting

    Pound is awesome but it has a few very serious problems:

    1) Memory leaks - in our environment pound leaked memory like a siv. I had a cron job that restarted it daily it was so bad. In Pound's defense, this may have been a leak in the openssl libs.

    2) Compatibility - Older versions of pound had very serious problems with some browsers. We had many clients that should not access the secure website. You had to upgrade to the pound-current tarball to fix it, which probably introduced the memory leak mentioned above. :)

    3) It is slow - I hadn't noticed how slow it was until we replaced it.

    4) Pound does not scale well when used as a load balancer. We couldn't get it to handle more than 100 concurrent connections. This may have been a hardware limitation (was not a dual proc, had only 1 gig of ram.)

    We replaced pound with an Intel SSL accelerator and haven't looked back. It rocks.

  3. Re:Some advice... by Peter+Cooper · · Score: 2, Interesting

    Regarding your latter idea, wouldn't that screw things up when it comes to running CGI scripts, and the like? After all, every single thing would be running as the apache process, rather than in a chrooted environment, as many secure systems do. I may, of course, be missing the point.

  4. wow by man_ls · · Score: 2, Interesting

    You sir, are in the exact same situation I was in just two days ago.

    My conclusion:

    Moving to one process to serve all requests, SSL and non-SSL, is more of a hassal than it's worth.

    SSL and Non-SSL on one process requires IP-based vhosting. If you're using vhosts you probably don't have multiple IPs per server. Thus you must use name-based vhosts, and SSL gets confused.

    I gave up and installed two processes and am very happy with that solution.

    Apache+OpenSSL 2.0.48/Win32 on Windows Server 2003.