Brian writes: >> If performance is that critical, you shouldn't be using Apache. > > Why's that? Please enlighten me... Apache is not scalable. Before everyone starts freaking out, let me explain. I'm not talking about the few hits a second from Slashdot that flooded your DSL line and crashed your 486. Apache will handle that fine. I'm talking about situations that most people will never run into, such as needing to push several hundred megabits of free hosting content or running a web application with many thousands of concurrent users. Those are the situations where worrying about .htaccess files might start to matter. (But on modern computers, probably not. I imagine that documentation was written when a good webserver was a 32MB Pentium 90.) Requiring a separate process per connection puts a fixed limit on the number of concurrent connections you can serve. A properly tuned box can usually handle many more than this. High traffic static sites, such as free hosts, are usually limited by bandwidth, operating system buffers or disk I/O. Apache's process model will cut off users well before these limits are reached. In addition, the extra load of having all those processes will have a noticable effect. Dynamic sites are often limited by memory or CPU. When you compile things like SSL and PHP into Apache, the processes get fat. Serving lots of clients causes there to be lots of bloated processes. It is much better to keep the content producers out of the web server and talk to them via FastCGI (for example, using mod_fastcgi). But the typical Apache way is to compile everything into the main server. As an example, you can handle the same amount of PHP traffic with only a few FastCGI processes that would take dozens of Apache processes. -- David Phillips <david at acz.org> http://david.acz.org/ _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list