Thomas Eibner writes: > So you say that it's bloated to put in php as a module, but you never > the less implemented something for thttpd to run php as cgi? Nice. No. As I said, it runs as a CGI, not part of the web server. My patch adds handler support so that .php scripts are executed using the PHP CGI binary. Without this type of support, you would need to make your PHP scripts CGI's (i.e. make them executable and include the #!/usr/local/bin/php line). The advantage here is that you only pay for PHP when you are using it, not on every request. If you compile PHP statically, the performance is decent. On most sites, the majority of files are static (images), so this works out pretty well. I have been running this patch for a few months on my development box. > I believe apache.org is much of a testimony to Apache being able to > handle the load for whatever Duncan can throw at it 1). > What Duncan needs to make sure is that he has the pipe that can serve > it and as you point out, enough memory to have enough childs running. > > 1) http://www.apache.org/server-status > 3788 GB over the last 20 days, which is about 8 GB/hour or about > 2MB/s (byte, not bit). And this is without a new release within > those 20 days afair) That's only 38 req/sec, which is not much. My guess is that the Apache server on apache.org is not running mod_php or many other modules, causing the processes to be a lot smaller and making it irrelevant to his needs. 16mbit is nothing when it's large files (like the Apache source). Get Apache (especially with mod_php) to push 80mbit when it's 10k images, then I'll be impressed. There are some good benchmarks here: http://www.zeus.com/products/zws/capacity/scalability.html -- David Phillips <david at acz.org> http://david.acz.org/ _______________________________________________ Twin Cities Linux Users Group 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