FreeBSD 5.4 or 6 for DB server with 9500S-4 ?

[Ken Gunderson]

On Fri, 25 Nov 2005 17:20:37 -0800
ray at redshift.com wrote:

> | 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.

There's this out of Source Labs.  Can't speak for validity of testing:

<http://66.102.7.104/search?q=cache:i_OKZO5_CUQJ:www.sourcelabs.com/pdfs/SourceLabsPHP4vsPHP5.pdf+php4+vs+php5+performance&hl=en>

> 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.

One of the superiorities of *BSD compared to some other *nix like OS's
out there that include the kitchen sink in a default install...  >;^)
  
> | 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).

You're mixing and matching Lighttpd and thttpd here?  I was referencing
Lighttpd.  In either case, your experience seems incongruent with some
benchmarks published on the Lighttpd website (but then that's also why
you should profile your stuff for your real world;). In case you missed
them:  

<http://www.lighttpd.net/benchmark/>

These have been online for quite some time now and I've not heard any
cries of "foul" from the competition...

> | 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?

I didn't save anything I did w/the php stuff- it was just some quick
ab's with php4 to satisfy my curiosity.  Here's some quick and
dirty stuff I put online for a ROR app though:

<http://typo.leetsoft.com/trac/wiki/TypoOnFreebsd>

It's turned out to be a fairly popular read by the Typo crowd. 
 
> 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 :) 

Lighttpd can be a bit challenging at first blush as the docs can be a
bit terse in places. Not that it's all that complicated but it's just
different from Apache think.  The mailing list is very responsive.  See
the doc I pointed to above for an example of FastCGI config that's
easily modified for php app. Basically I just run a really striped down
minimal instance of Lighttpd to manage the FastCGI processes. More
flexbile and easier to manage that SuExec.

> | 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.

I didn't do anything formal but did run a few Ubench tests.  Granted
it's a synthetic test but does provide a frame of reference:

dual 246's w/4GB DDR 400:

Ubench CPU:   222794
Ubench MEM:   200592
--------------------
Ubench AVG:   211693

Same machine except dual 252's:

Ubench CPU:   290450
Ubench MEM:   248157
--------------------
Ubench AVG:   269303


The 252's came at a deal I coudn't refuse.  Last I looked the 246's were
the sweet spot on price/perf though (are the 90nm core versions in the
channel yet??  If not then they soon should be and might be worth the
wait??).  

> | 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 :-\

One would think that Xeon would be quite sufficient for firewall, eh?
You may want to check out PF and Carp.  I've been using PF since before
Hartmeir's code had been merged into official OBSD dist and never
looked back.  Also been the hook that converted a few of my Linux
buddies to *BSD;)  At least for their firewall needs...

I'm certainly no guru compared to many on this list and this may be
getting a bit off topic for freebsd-amd64.  But I have been around the
block a time or two and it's all related to performance of various
apps/ configs under amd64 so thought I'd contribute my $0.02 in hopes
it may be of some benefit to Olaf's adventures in FreeBSD land.  Hope
I've not wandered too far astray...

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?