Memcaching Plan of Attack

[Iain Barnett]

On 11 Apr 2008, at 1:39 pm, Aaron Trevena wrote:
> On 11/04/2008, Peter Corlett <abuse at cabal.org.uk> wrote:
>>  I'd probably start looking at what database queries are being  
>> performed and
>>  whether there's any repetition, deviation or hesitation, and then  
>> optimising
>>  the hell out of those.
>
> I'd look at where different users are look at the same info
> repeatedly, and how much work it is to fetch it - sometimes it's
> easier to optimise on the way in rather than out by using seperate
> denormalised tables, reverse indexes, etc.
>

Usually, you'll find that the tables haven't been properly  
normalised, and have lots of bad indexes (not updated; on booleans or  
variable width; not very unique) or none at all.

Look out for boolean fields in your tables being used to define sets  
(used in WHERE clauses to select a set), and then you know the  
database design is slowing you down. Try looking out for conditional  
logic in stored procedures too - not all databases cache each branch,  
so the first condition used becomes the cached copy and then  
everything other call to a different branch is the same performance  
as ad-hoc queries.

Denormalisation is the very last thing I'd do in an OLTP database.


Iain