Memcaching Plan of Attack
iainspeed at gmail.com
Fri Apr 11 14:11:31 BST 2008
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
>> 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.
More information about the london.pm