Fetch performance #

This page is for designers whose pages got slow. In templates, almost all cost comes from fetches and the attributes that quietly fetch (children, parent, data_map). The rules below keep the number of database queries small.

Contents #

1. The rules
2. Attributes that fetch
3. The loop trap
4. Measuring

The rules #

1. Fetch once. Store the result in a variable; pass it to parts as a parameter.
2. Always a limit on list and tree; paginate with offset and a list_count.
3. Filter in the fetch (class_filter_array, attribute_filter), not with {if} in the loop.
4. Prefer what you already have. In the pagelayout, $module_result.content_info holds the class, node id, depth and URL alias of the page without a fetch.
5. Cache what is the same for many visitors: menus and footers in cache-blocks (Cache-block).
6. Keep full views cacheable so the view cache serves them (Caching for designers).

Attributes that fetch #

$node.children on a folder with thousands of items is the most common cause of a slow page: use a fetch with a limit instead.

The loop trap #

{* slow: one fetch per child *}
{foreach $children as $child}
    {def $sub = fetch( 'content', 'list', hash( 'parent_node_id', $child.node_id ) )}
    ...
{/foreach}

Ten children mean eleven queries, a hundred mean a hundred and one. Instead, fetch the descendants once with tree and depth 2 and group them in the template, or show the sub-level only on the child's own page.

Measuring #

On a test siteaccess, enable the debug output for your address ([DebugSettings] DebugOutput=enabled, DebugByIP=enabled, DebugIPList[]): it shows the time of the page and the database queries. Compare before and after a change, with caches cleared and again warm.

Related pages #

• Fetching nodes and lists
• Theme performance
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.