PHP performance on FreeBSD 4.x and 5.x

[Danny MacMillan]

On Fri, Oct 29, 2004 at 05:36:05AM -0600, Paul Robinson wrote:
> On Fri, Oct 29, 2004 at 08:29:40AM +0200, Jakob Breivik Grimstveit wrote:
> 
> > At my local *BSD- and Linux User Group [1} we yesterday had a
> > presentation by eZ Publish [2] a PHP based CMS and portal builder
> > framework for web.
> 
> Oh, another one. What the world needs is more PHP based CMS and portal
> builder frameworks for the web.

Ordinarily I would agree with this sentiment, but eZ Publish is unique.
Their data model has characteristics I haven't seen in any other open
source CMS.

> > During the session it was stated by the speaker mentioned that
> > running their system on FreeBSD (both 4.x and 5.x) not necessarily
> > would be a good thing due to a lot of filesystem calls in their
> > product, which PHP on FreeBSD had performance problems with under
> > high load. In other words he did not recommend FreeBSD as server
> > platform for eZ Publish (or any other PHP software for that matter)
> > where a high number of visitors was probable.
> >
> > I found this to be difficult to believe, and decided to ask you about
> > whether this might be the case or not.

I doubt FreeBSD is at fault for this, but I can verify that (at least)
on FreeBSD it runs ridiculously slowly.  At least an order of magnitude
slower than any other web application I've ever used.  My testing was
by no means rigorous, and I was using old hardware (400MHz K6, 384MB),
but on a single user system with no other load it should not take 10
seconds to produce a simple front page with 3 article summaries.  This
was a while ago, I don't have actual timing information, but put
it like this:  by the time the page was served, I had lost interest
in seeing the result.  EVERY page was abysmally slow.

The performance was so bad that even if some flaw in FreeBSD is making
it slower than it should be, I have no confidence that it would improve
enough under other operating systems to be scalable. Performance did
improve by about 30% when using turck mmcache, but again, not by enough.

> Well, first off, they've just told you that their product doesn't scale
> because it's I/O bound to disk. This should make you question their
> competence, seeing as this is a web application. I for one, would be
> reluctant to buy their product if they had just told me it'll start to
> break because they can't engineer their way around a known performance
> constraint. Especially when there are open source solutions that will.

Not functionally comparable to this one; it really is different.  But
unless you have the budget for some serious iron, I wouldn't even go
there if you need scalability.  Opinion not scientific, yadda ya, and
I'd love to be disproved, but ... it's a clunker.

-- 
Danny