[development] Caching, caching, caching...

[Gerhard Killesreiter]

Dries Buytaert wrote:
> 
> On 12 Jul 2006, at 00:01, Gerhard Killesreiter wrote:
>> Now the question is if we want to go down this road. To properly
>> invalidate the cache requires to implement all sorts of hooks (forum
>> module needs _comment and _user for example) which you would not need
>> otherwise. This complicates the code quite a bit.
> 
> Personally, I'd not optimize with MySQL's query cache in mind.  If the 
> folks at MySQL improve their query cache implementation, our efforts 
> might have been moot. 

True. The most important aspect of mysql's query cache is that it isn't 
that well suited for a dynamic application such as Drupal the hit:miss 
ratio is only about 3.5 on drupal.org.


> I'd focus my energy on high-level improvements, 
> rather than low-level improvements.  That is, I'd focus architectural 
> changes that reduce the number of SQL queries or that simplify complex 
> queries (eg. less joins).  For example, the node table and 
> node_comment_statistics table have a one-on-one relation and could 
> potentially be merged.  I'm not sure what it would buy us, but it might 
> be worth it.


I think that the potential for such changes is rather small if we still 
want to keep a reasonably sane DB schema.


> Maybe we should run the modified devel.module on drupal.org to see what 
> the most expensive queries are?

SELECT * FROM url_alias, I'd be surprized if that had changed. The 
individual query is very short but there are probably 120 per page on 
average.

>  You know, accumulate results over 
> multiple page views.  Do we have recent data query data from 
> drupal.org?  Let's start by identifying some key bottlenecks.

The forum queries that I cached in my patch are also among the more 
prominent ressource hogs on drupal.org, IIRC. Caching them might give us 
an immediate benefit. This of course only applies if the cache hit:miss 
ratio is significant. Maybe I should try them on drupal.org...

Cheers,
	Gerhard