OT: why are LAMP sites slow?

[Paul Rubin]

Kartic <removethis.kartic.krishnamurthy at gmail.com> writes:
> And the reason for that I probably because of the way the language is
> used (PHP) (this is a shot in the dark as I have not looked into
> Mediawiki code), and compounded by probably an unoptimized database.

I have the idea that the Wikipedia implementers know what they're doing,
but I haven't looked into it super closely.

> I don't want to start flame wars here about PHP; I use PHP to build
> client sites and like it for the "easy building of dynamic sites"
> but the downside is that there is no "memory"...every page is
> compiled each time a request is made. I doubt if Wikipedia site uses
> an optimizer (like Zend) or caching mechanisms. Optimizers and/or
> PHP caches make a huge performance difference.

They do use an optimizer similar to Zend.  They also use Squid as a
static cache.

> Also, PHP has put dynamic sites within easy reach of several
> programmers who slap together sites in no time. These sites may have
> spaghetti code and even the best infrastructure is not enough to
> support shabby design (code, db setup and even server tuning). I have
> seen people become programmers overnight! There are also LAMP sites
> that use Apache 1.3 that is a resource hog; I guess production sites
> do not want to upgrade to Apache 2.x/PHP combo!

Hmm, I wasn't aware that Apache 2.x gave any significant speedups
over 1.3 except under Windows.  Am I missing something?

> The way to go is to build around application servers, IMHO. I like the
> Twisted.web/Nevow methodology, though for simple situations it may be
> an overkill. 

Hmm, I'm not familiar with Nevow.  Twisted is pretty neat, though
confusing.  I don't see how to scale it to multiple servers though.

I'm asking this question mainly as it relates to midrange or larger
sites, not the very simplest ones (e.g. on my personal site I just use
Python cgi's, which are fine for the few dozen or so hits a week that
they get).  So, the complexity of twisted is acceptable.

> From my experience it is an overall tuning thing. Usual culprits are
> untuned Linux boxes, unoptimized database design, poorly designed
> queries and/or poor application logic...and ah! table-driven
> pages. Pages built on tables for the layout kill the browser. CSS is
> the way to go.

Yes, good point about html tables, though I'm concerned primarily
about server response.  (It's off-topic, but how do you use CSS to get
the effect of tables?)