[development] MYSQL queries and Modules

[Pierre Rineau]

On Sat, 2011-02-26 at 09:22 -0800, nan wich wrote:
> 
> When I develop modules, I have Devel turned on. One main thing I look
> for is repeated queries. Unfortunately, I find a lot of them,
> especially in other people's modules. I'm glad to see global caching
> available in D7 so that sub-functions don't have to repeat information
> gathering that another function has already done.

If you mean drupal_static() then you should not say "global caching" but
"registry pattern", it avoids confusion on the implemented pattern and
open it to a better understanding and probably a better usage.

> As a teacher once explained to me, "All generalities are false,
> including this one." Some of your statements are decent guidleines,
> but hardly universally true. For example, "avoid ... hook_init" --
> sometimes it is necessary, so one must be discerning in applying this
> rule.

Sometimes, but when you are writing a hook_init(), in 90% of the cases
you are wrong. This hook is run even when generating image (cache|style)
derivative, which means that in case of a 404 error, you run a whole
bunch of totally unnecessary and/or really costly operations.

> Indeed using cache is a balancing act. When I added caching to one of
> my modules, I checked its performance impact. Using the main cache
> table made things worse because cache_get queries were taking longer
> than no caching at all. So I created my own cache table and it solved
> the performance issue that I was attempting to fix. I still don't
> think it was a good substitue for a properly tuned database server,
> but few people have those.

Using a different cache because it increases performances is not always
the good way to go. If fetching a cache in global cache table is slower
than rebuilding your data, then you should probably *always* rebuild it.
Because if you are slower in the cache table than in your own doesn't
mean you solved the problem by doing the custom table, it only means
that you delayed its negative effects because as soon as the site will
scale in term of data volumetry, it will then happen again.

By using this kind of judgement instead of separating logically caches
(critical/always used cache such as bootstrap and menu, or heavy and
ponctual caches such as aggressive page cache) you break the sysadmin's
work which is to distribute those bins over different cache backends
(memcache, apc, xcache, database, ..) depending on the data volumetry
and physical environment measured performance impact.

> Nancy

Pierre.