[development] Caching, caching, caching...

[Khalid B]

On 7/22/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
>
> 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?

For 2 and 3, giving the end user (non technical  site admin) regexp
is suboptimal. I was thinking more of a using regexp internally,
perhaps via an API, and modules would provide a user interface
on top of it, such as pathauto, where they can select caching
for nodes, ...etc.