Thomas Eibner writes: > But most people that do use php, likely use it all over their website. That doesn't matter. Don't fall into the trap of thinking that just because the page uses PHP that every request is PHP. On a typical site, you will have at least 10-20 images for every page request. For many sites, the number is much higher. As an example, loading the front page of Slashdot required an extra 54 image requests. > Furthermore, when you load php you might see your memory usage > increase, but if it follows suit with other apache modules I've > worked with (mod_perl) the majority of it is shared memory and thus > doesn't have as large an impact as you would think. Unfortunately, that's not the case. I have a box running Apache with mod_php4 and mod_ssl and the processes take at least 15-30mb. That is real memory, not shared (the RES line from top on FreeBSD). > Even if it did > make a difference, it should not have an impact on the number of > requests that you can serve from Apache when it's static images > unless you goofed up and made php handle the mime-types for the > images. The impact is that each process contains PHP, therefore requiring a lot of memory, thus limiting the total number of processes you can have running. If I can only run twenty Apache processes before running out of memory, then that limits me to serving twenty clients at once. The number of actual users can be significantly less, since some browsers will use multiple connections. > And if you're in a high traffic/hit environment chances are > you have a seperate webserver for serving pictures. If you use a well designed web server like Zeus, you don't need two servers to work around a bad design. A possible alternative might be to use PHP under FastCGI with Apache. I don't think many people do that, but it could have significant performance advantages. > As to pushing 80mbit with Apache, I didn't have a problem doing just > that at home right now. > Serving a 10240 byte file over 100mbit network: (no keep-alive) > Transfer rate: 11294.81 [Kbytes/sec] received There is a huge difference between serving over a local network and serving real traffic. A good number of clients, perhaps a majority, will be modem users. This means connections stay open for much longer and have a lot of latency. Even with broadband, there is still a significant amount of latency involved. Try a concurrency of at least 500-1000 if you want to get anywhere close to real world usage. > Serving a 10240 byte file over localhost: > Transfer rate: 22876.10 [Kbytes/sec] received Any tests over localhost are basically worthless for a number of reasons. > These "tests" are about as trustworthy as any other test that is > put up on the web Correct. It is difficult to adequately simulate web traffic. > Of course this is not on a live site, nor is it from real clients > whose behaviour would be much different, but noone in their right > mind would try to serve all this from one machine anyway. Wrong. It is easily possible to serve this much traffic from one box. People were doing this at least three years ago. > Server: Apache/1.3.27 (Unix) PHP/4.3.1 > Vanilla compile on hardware turning two years in july. No excessive > memory use from my 200 childs with PHP loaded. Sure, PHP isn't going to be huge just from being loaded (though it wouldn't really surprise me). Run some real scripts first and watch them grow. Again, real world usage. > I would expect nothing but good benchmarks showing how well Zeus > performs on the product website. I've seen nothing in my experience with web serving to indicate that they are misleading or incorrect. Given the architecture of Apache, it is quite easy to see why they are the way they are. Try benchmarking 1000 concurrent connections on Apache and on Boa or thttpd (or download the evaluation version of Zeus and try it out for yourself). -- 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