[development] Drupal performance patches: call for action

Gerhard Killesreiter gerhard at killesreiter.de
Wed Aug 1 10:50:46 UTC 2007

Hash: SHA1

Dries Buytaert schrieb:
> On 01 Aug 2007, at 11:37, Gerhard Killesreiter wrote:
>> Yeah, I'd be one of the people who have reservations on this, especially
>> on the node_counter part. This will give a lot of writes to the node
>> table, which is a stupid thing to do considering that the rest of the
>> table is -+ static (compared to the node counter table).
> Here is the concise summary:
>  1. Locality of information is important -- it avoids queries.  If you
> use A and B together, you want to get that data in one query.  This
> holds for both spatial and temporal locality.
>  2. You want to split cold and hot data -- it avoids having to load
> large amounts of data into memory.
> Sometimes, both are at odds -- especially when MySQL's locking comes
> into play.

I didn't even mention locking. :p
Also, Köhntopp mentions specifically InnoDB, not MyISAM, so I believe
his analysis doesn't only apply to MyISAM.

> In case of the user access table it might make sense to split of the
> access-field.  It's a "cold" field; it's hardly ever read but it does
> get some writes.

Right. Also the "login" field.

> Because the field is almost never read, the fact that
> we loose spatial locality isn't much of a concern.
> The node_counter field is both read and write heavy.  By splitting it

If you use the feature, yes. There is good reason to not use it.

> off, you loose the locality advantage and it's not clear what is more
> important: the fact that we can simplify thousands of read queries, or
> the fact that we can avoid some table locking.  Only extensive
> benchmarks can tell.

Yeah, that sums it up neatly. Problem is: Nobody is going to do
benchmarks extensive enough to tell.

Version: GnuPG v1.4.6 (GNU/Linux)


More information about the development mailing list