[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