Optimisation process

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
OK, following on from a thread above. Where do most people start their
optimisation and how?

a: Query analysis - both the queries themselves and then using joins, etc?

b: RDBMS tuning?

c: Webserver tuning?

d: Analysis of executed code, looking for repeated and redundant
function calls?

e: Code refactoring, reducing duplication?

f: Output buffering, http side stuff?

g: Caching?

Re: Optimisation process

Hugh Oxford wrote:
Quoted text here. Click to load it

I start to optimize when I have a performance problem.  Otherwise, it's
always code for clarity and maintainability.

Quoted text here. Click to load it

I determine the cause of the performance problem and resolve it.  What I
fix depends entirely on the cause of the performance problem.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Optimisation process

Hugh Oxford wrote:
Quoted text here. Click to load it

a. Don't use standard 'written in PHP' libraries that contain loads of
dross that has to be loaded.

b. Don't use massive one size fits all CSS style sheets that all have to
be sent to the browser: Remember that style sheets are there to reduce
the amount of content sent, not to increase it.

c. Use output compression to reduce amount of content sent.

d. One decent SQL enquiry formulated efficiently is a lot faster than a
set of them formulated badly with Inadequate indexing.

AS far as caching goes and all the other things, mostly that is done for
you by pretty smart algorithms: Unless your application has stepped far
outside the normal limits, its not worth doing.

Re: Optimisation process

Quoted text here. Click to load it

I strongly disagree. The default configs for the webservers I've used
ship with no caching info for static content - how would the
developers know how often you change your gif files? It will vary by
site, but reductions in bandwidth of 60% or more are not uncommon
after adding caching of static content.

For PHP and database caching it will vary hugely depending on the
nature of the application; just going with the default no caching of
PHP and enabling any database caching is a safe rule of thumb.


Re: Optimisation process

Quoted text here. Click to load it

The first step is to find out what needs to go faster. If your DBMS
supports it, enable slow query logging. Enable logging of transaction
times in your webserver. Analyse the data. Sometimes its OK for a page
to take more than 20 seconds if its just getting hit once a day - but
if you're using MySQL (or even SQLite) then that could be having a
knock-on effect on all other database accesses at the same time. I
usually go with hits X duration to pick up the areas which could
benefit from optimization (non-MySQL env). Also, monitor memory, CPU
and bandwidth usage on your boxes.

What you do next depends on the patterns you see in the data you
gather, and what the user experience is like. Its really all about
experience and available information (and, Sssshhhh, don't tell
anyone, guesswork).

If you are seeing some URLs taking longer than 5 seconds, then I'd
recommend looking at tuning the SQL first.

Quoted text here. Click to load it

If you're saying that you don't currently do any joins in SQL then FFS
get with the program!

Reducing duplication of code/eliminating redundant code will not have
much impact on system performance and is expensive in terms of effort
(but does make managing the code much easier). Output buffering
doesn't have a lot of impact. In my case enabling gzip compression of
all html mime traffic leaving the webserver had a huge benefit on
performance - although it requires extra CPU to do the compression,
offloading the request sooner meant an overall reduction in CPU usage,
load and response times. Other people on this NG have claimed the
opposite though.

Operating system and DBMS tuning should give a small improvement
across all URLs (I'd classify any sort of DDL as SQL tuning, and
reconfiging your DBMS as DBMS tuning).

Get a PHP accelerator (if you've not already got one).

Getting your static content caching right can mean a **massively**
improved user experience - but unless your site is very heavy with
static content and bandwidth is an issue, then it doesn't bring a lot
of benefits server side. You really to know what you're doing though.
Mark Nottingham's guide is a good introduction but there's no good
guide I'm aware of for SAAS apps.

IME, using a reverse (caching) proxy doesn't really pay off from a
performance perspective.



Site Timeline