Posted by C. (http://symcbean.blogspot.com/) on 01/18/08 13:16

On Jan 18, 3:47 am, Gilles Ganault <nos...@nospam.com> wrote:
> On Thu, 17 Jan 2008 20:30:10 -0500, Jerry Stuckle
>
> <jstuck...@attglobal.net> wrote:
> >The real question here is though - are you observing performance
> >problems? Or are you prematurely optimizing?
>
> I'm going step by step so as to understand where performance can be a
> problem. It makes sense that we should avoid having the PHP
> interpreter needlessly reparsing pages it already parsed into opcode
> before, but I'm clear as to what I _shouldn't_ include in a PHP page
> so that it's kept in the cache by the accelerator.
>

The only real problem is the sizer of the cache - it needs to be large
enough to give a good hit ratio while not stealing resources from
apache et al. Guesswork and experimentation are the only way to solve
this.

Note - template systems will typically slow performance compared to
code written without them - but for team development they save a lot
of hassles - unless you're Google, adding hardware is cheaper than
programmer time.

> Without experience in this sort of thing, it's difficult to tell. A
> big "load average" as reporter by top (60 instead of below 1) is
> apparently a big sign of overload, but we're having a difficult time
> tracking down where the problem lies. Maybe 400 sleeping processes and
> 15MB Apache processes are a sign of bad I/O (hard-disk, network, or
> MySQL waiting to service queries).
>

Make sure you've got mod_gzip configured and you're compressing output
from PHP (getting the request off the server quicker typically
outweighs the processing overhead by a huge factor).

Next - make sure you're returning good caching information from every
script and bit of static content on your server. Watch out for 304
responses - if you've got the caching right you may still get a
benefit by eliminating the conditional part of a if-modified-since /
if-none-match request.

> It's just an opportunity for me to really get down to how LAMP
> applications should be built so they can scale beyond a few ten's of
> users.

? You've got load problems with tens of users??????!!!

Then the above are not likely to help.

You should probably focus your efforts on the database - switch on
mysql_slow_query logging and fix all the problems - start with the
database schema - once you've exhausted everything there, try adding
hardware.

C.

[Back to original message]