[development] Caching, caching, caching...

Dries Buytaert dries.buytaert at gmail.com
Sat Jul 22 15:30:16 UTC 2006


On 22 Jul 2006, at 03:18, Khalid B wrote:
> This way, we cut down on the number of useless aliases (for that
> particular site). If a site restricts aliasing to $_GET['q'] of
> ^taxonomy/term/\d$
> ^taxonomy/term\d/feed$
> ^node/\d$
> ^node/\d/feed$
> Then menus become a non issue. They do not take up space  in
> the database, they are not queried either.
>
> The above pattern is enough for the majority of sites (perhaps with
> user/* as well). Modules like pathauto can use that to
> add or remove patterns too.

So we have a number of viable ideas here.  Let's try to summarize them:

1. Build a caching algorithm that uses an heuristic to pre-load  
frequently used URL aliases.

    * Advantages: transparent, no configuration required

    * Disadvantages: it a heuristic, we don't know how it would  
perform, it might be tricky to implement, and MySQL does this  
implicitly (but not as aggressive).

2. Provide a textarea that allows administrators to _white_list_ URL  
patterns.

    * Advantages: fine-grained control, easy to implement

    * Disadvantages: users usually don't like messing with regular  
expressions, it might take a lot of effort to get the list Just  
Right, and it takes a certain amount of familiarity with Drupal's URL  
scheme (learning curve for new Drupal users).  The behavior might be  
confusing: you add an alias, and it doesn't work because you forgot  
about the list of URL patterns.

3. Provide a textarea that allows administrators to _black_list_ URL  
patterns.

    * Advantages: fine-grained control, easy to implement

    * Disadvantages: users usually don't like messing with regular  
expressions, it might take a lot of effort to get the list Just  
Right, and it takes a certain amount of familiarity with Drupal's URL  
scheme (learning curve for new Drupal users).  The behavior might be  
confusing: you add an alias, and it doesn't work because you forgot  
about the list of URL patterns.

4. Stop doing SQL queries when you cached all possible URL aliases.

    * Advantages: transparent, no configuration required, can co- 
exist with (1), (2), (3) and (5).

    * Disadvantages: only works for a subset of all Drupal sites, not  
a solution for larger Drupal sites.

5. Improve Drupal's high-level page caching so we have to rebuild  
pages less frequently.

    * Advantages: no configuration required, can co-exist with (1),  
(2), (3) and (4), eliminates many more SQL queries.

    * Disadvantages: doesn't work for authenticated users.


Thoughts?

--
Dries Buytaert  ::  http://www.buytaert.net/



More information about the development mailing list