Date: Fri, 25 Nov 2005 17:20:37 -0800 From: ray@redshift.com To: Ken Gunderson <kgunders@teamcool.net>,freebsd-amd64@freebsd.org Subject: Re: FreeBSD 5.4 or 6 for DB server with 9500S-4 ? Message-ID: <3.0.1.32.20051125172037.00a4aa68@pop.redshift.com> In-Reply-To: <20051125135148.053d2c80.kgunders@teamcool.net> References: <3.0.1.32.20051125121159.00a5d2f8@pop.redshift.com> <3.0.1.32.20051125041044.00a47720@pop.redshift.com> <3.0.1.32.20051121055411.00aa1490@pop.redshift.com> <20051119200222.V2029@roble.com> <20051119120051.39BE216A41F@hub.freebsd.org> <20051119200222.V2029@roble.com> <3.0.1.32.20051121055411.00aa1490@pop.redshift.com> <3.0.1.32.20051125041044.00a47720@pop.redshift.com> <3.0.1.32.20051125121159.00a5d2f8@pop.redshift.com>
next in thread | previous in thread | raw e-mail | index | archive | help
| I have run across published benchmarks concluding php5 is indeed faster | than php4. I've not, however, run across published benchies to the | contrary. Not saying they're not out there, nor speaking for the | validity of those I have seen, but just pointing out that benchmarks | can be misleading, confusing, etc. and of limited use unless you | happen to run across one that mimicks your config, or you do them | yourself. I've run benchmarks here (first hand, myself) that show PHP4 is about 10 to 15% faster as I recall. I don't recall if that was using PHP4 as a static compile into apache and PHP5 as a DSO or how I had it all configured (it's been a while), but at least in my testing (and I try to keep apples to apples), PHP4 was quite a bit faster. The benchmarks I ran are spread across a messy excel spreadsheet, but if you want to see them, I'll be happy to e-mail them to you and/or upload them along with my SQL benchmarks. Like I say, as I recall, I tested a simple install of PHP4 against a simple install of PHP5 and PHP4 was the clear winner. Same with Apache 1.3.33 vs 2.0.5x Anyway, I always suggest people run their own benchmarks, in their own environments and not rely so much on what other people (including me) say or what other benchmarks show. You might be surprised that some of the older code runs faster. Also, you'd be shocked how much speed you can get from PHP and Apache if you compile out modules that aren't used. | Regarding Apache- I've taken to running my php stuff via FastCGI under | Lighttpd as unprivileged user on high port and then proxying via | Apache2. (Some of caching stuff comes in handy. Granted Squid is a Lighttpd isn't bad, but if you tweak apache (at least 1.3.33) properly, you can reach the same speed levels. In fact, in the testing I did, a stripped down apache was able to nearly match thttpd. And just for fun, I wrote a 3 or 4 line C++ server to see what the theoretical speed was. All the server did was listen on port 80 - as soon as it got a connect, it sent the web page. It didn't wait for GET or anything like that - just bang, page sent, connection closed. Using that as the "redline" for the machine, I think I was able to get thttpd to about 90% of it and apache 1.3.33 to something like 75 or 80% of it (those are just off-the-top-of-my-head numbers, but you get the idea). | better choice for serious use. ) This config pretty much screams | performance wise. do you have any ab figures for 1k, 5k html or maybe some php programs as far as page loads per second, by any chance? For various reasons discussed a while back on | another thread, best webserver perf is seen under FBSD-i386. The AMD64 | stuff absolutely rocks when you get into larger db's needing more ram, | etc. In the testing I've done (specific to .html and php pages), I seem to remember that i386 did well on small pages (under 1k), but amd64 did better on pages that were 1k and above. Running php under FastCGI also sets you up for inexpensive load | balancing solution. Just throw relatively inexpensive single cpu, sata | based machines in front of the db server. Anyhow, just throwing this | out for what it might be worth. If you've not checked out "Lighty" | before you may want to take a gander: | | <http://www.lighttpd.net>; | | Here's the FastCGI stuff: | | <http://www.lighttpd.net/documentation/fastcgi.html>; Thanks! :) I've played with lighttpd. I think I tried using fastcgi, but I can't recall now if I ever got it to work or not. That might have been the one where my eyes glazed over and I gave up :) | I'm seriously considering using mysql-5 for my latest project as well- | for similar reasons outlined above. A dul opteron system has got | plenty of power to spare for my purposes so squeezing out the last bit | hasn't been an issue. I've got 252's, 250's, 246's, and 244 boxes. | The 252's are "wickedly fast" but the 244's are still more than | adequate for many purposes. Yeah, I'm going to play with MySQL 5 soon also. I've been running the Dual Opteron 246's here (single cores). I would love to run some 252's, but since I'm a cheap SOB, I can't bring myself to spend the extra on the CPU's :) Do you happen to know (roughly) how much of a performance boost the 252's give you as compared to the 246's? I think our Tyan S2881 boards will probably support the 250's or the 252's. | Ditto:) The point of all this being that there are different | perspectives out there on this stuff and one needs to decide what's | best for their set of circumstances. I couldn't agree more. At the end of the day, it pays to test everything on your own platform and with your own application in order to determine what works best. What works for Ken isn't always what works for Ray or what works for Olaf or Nathan, etc, etc :) | AH-- one last thing- if you need to run a firewall check out pf ported | from OpenBSD. I built a router using FreeBSD and run ipf on it. I have our load balancers (Radware units) setup in local triangulation. It's nice to have ipf handled on a central machine as opposed to on each server. I was surprised how much of a performance boost you get if you don't run ipf :) Now I just need some of those 252's for the router (it's currently a single Xeon :-\ have a good weekend. Ray
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.20051125172037.00a4aa68>