Template options & performance

[Don Chambers]

So, here I am writing a template with a TON of template options, and I begin to wonder the performance impact.....

I remember during bulletproof development that we removed all the option descriptions, but made the option itself more descriptive. Was that for performance, or just file size?

Is there a database query for every page view to determine the options? If so, is that a huge performance hit relative to everything else that is happening?

[Don Chambers]

On a related note, what is the performance impact of writing all tpl code into a single file, vs. doing something like {include file="whatever.tpl"}?

[garvinhicking]

Hi!

Descriptions can be neglected in performance impacts. This was more a usbility thing, not a performance thing.

Like you mention, the config.inc.php is parsed everytime you view a blog page. If you load theme options for every page (this is usually the case) this means yes, there is a DB query - but for all of them. The more rows/options you have, the larger the connection time to the database, though. BP AFAIR has a check to only perform more intensive operations when the configuration page is called, this one is quite important.

Generally, the less code in config.inc.php, the better your performance.

On a related note, what is the performance impact of writing all tpl code into a single file, vs. doing something like {include file="whatever.tpl"}?

s9y requires the specific content, entries index.tpl template files, you cannot combine them. It's better to not create custom .tpl files that you include, because each include call has an impact on the file system.

Regards,
Garvin

[Don Chambers]

So imagine for a moment, 100 medium-high traffic sites on a single mySQL server, all running BP. Should I be concerned about the db queries created by loading template options, or are they insignificant relative to everything else?

I am not thinking of changing anything in bp, but I am working on a template where I built in a lot of additional template options for maximum flexibility, and am wondering if I should remove some of them from a performance perspective.

EDIT: For instance, would it be more - or less - efficient if all these template options that are being read via a db query then set to smarty variables were instead loaded from a php file?

And regarding tpls, I was not trying to combine any existing tpls... I was wondering if I should take a rather lengthy tpl file and cut portions out, such as certain foreach looks, and place them within their own tpl, the use include to call them.

[garvinhicking]

Hi!

Phew. 100 medium-traffic sites on one single DB server? That's already quite consuming. Usually, hoster's do not put more than 20-30 sites on a single DB instance.

Your problem would not be the Template Options itself, but rather the sum of all queries performed. You might want to put MUCH RAM on the MySQL machine, like 8GB or more, and using 4GB for a query cache alone.

EDIT: For instance, would it be more - or less - efficient if all these template options that are being read via a db query then set to smarty variables were instead loaded from a php file?

Yeah, if you could just set the required variables within config.inc.php in a hardcoded-way and pass them on to Smarty, that would be a lot less action to perform. Both in PHP parsing and MySQL implications. But of course you'd loose the nice menu-driven configuratbility.

And regarding tpls, I was not trying to combine any existing tpls... I was wondering if I should take a rather lengthy tpl file and cut portions out, such as certain foreach looks, and place them within their own tpl, the use include to call them.

No, better not. Even larger files perform much better than being split up into smaller ones, if in the end all data needs to be loaded. Splicing it up would only be useful if say 50% of a .tpl is only rendered in a sepcifiy IF-Branch and the rest is discarded.

Regards,
Garvin

[yellowled]

Guys, sorry to barge in here, but:

And regarding tpls, I was not trying to combine any existing tpls... I was wondering if I should take a rather lengthy tpl file and cut portions out, such as certain foreach looks, and place them within their own tpl, the use include to call them.

No, better not. Even larger files perform much better than being split up into smaller ones, if in the end all data needs to be loaded. Splicing it up would only be useful if say 50% of a .tpl is only rendered in a sepcifiy IF-Branch and the rest is discarded.

Does this mean something like:

Code: Select all

{if $view == '404'}
    {include file="404.tpl"}
{else}
    ...

should actually rather be something like:

Code: Select all

{if $view == '404'}
    <h1>404 - page not found</h1>
    <p> ... </p>
{else}
    ...

YL

[Don Chambers]

The webserver and mysql server are 2 different boxes, each with 8-12gb of ram and dual quad core zeon processors... and no, there are not 100 of them, I was just trying to demonstrate an extreme example. There are, however, at least a dozen decent volume sites on that equipment. Additionally, each of them also uses openx for ad placement.

I certainly like the menu driven template options, as they are much more user friendly.... a lot easier to check a radio button for "yes/no", or specify navlinks, etc in that manner, than it would be to open up a php file and specifically define a variable with the desired value....

But I am concerned about scalability - should I be? And should I be all that worried about template options, if in the grand scheme of performance, no matter how many there were, the performance implication is only a tiny piece of the total picture? Better to focus elsewhere for improvements on high load sites?

[garvinhicking]

Hi YellowLED!

This is a special case. it makes sense to outsource special files if they should be maintained on their own. the usability factor overweighs the performance impacts -- only in high-performance environments this would be suggestable.

Don, I think you should also better focus on other aspects. I believe the template options only contribute, say, 3% of the overall page performance, so they can often be neglected. What would be much more sensible would be to disable Read/Write ACL evaluation for categories, if you don't need them. Also eradicating counting entries for sidebar plugins makes up a lot of performance, not using the visitor plugin etc.

Regards,Garvin

[Don Chambers]

@YL - your 404 example I already handle exactly like your proposed alternative.. I do not use an additional tpl file, especially since it is a condition that only occurs once, and the code is just a couple of lines.

A better bp example would be template options for sitenav, or sidebar order. I realize we change classes on some of the containers, but lets assume for a moment it didn't. And lets assume we had the same basic building blocks of code: navbar, right sidebar, content and left sidebar. We have dozens and dozens of substantially identical code set up in cases for these sidebar/content options and navbar positioning options.

My curiosity was whether it would be a good idea to have, say navbar.tpl, rightsidebar.tpl, leftsidebar.tpl, and content.tpl..... then for each case, instead of having all this duplicate code, we did something like:

Code: Select all

<!-- case 1: 3 columns, sidebar-content-sidebar -->
{include file="leftsidebar"}
{include file="content.tpl"}
{include file="rightsidebar.tpl"}

<!-- case 2: 3 columns, content-sidebar-sidebar -->
{include file="content.tpl"}
{include file="leftsidebar"}
{include file="rightsidebar.tpl"}

The same thing could be done for navbar options.... if for no other reason, it seems easier to maintain the code... if we come up with a new concept, we typically have to insert that concept into each one of our cases.

@ Garvin, in addition to my questions in the prior post, I guess what I am asking is there anything to be gained by storing these template options in a php file instead of doing a db query... similar to how we have certain things stored in serendipity_config_local.inc.php.

[garvinhicking]

Hi Don!

@ Garvin, in addition to my questions in the prior post, I guess what I am asking is there anything to be gained by storing these template options in a php file instead of doing a db query... similar to how we have certain things stored in serendipity_config_local.inc.php.

Yeah, you would gain a 1-2% performance boost (one % remains because options still have to be parsed, and are not removed). but since it really makes it less flexible, I'd think about if those 2% are worth it...

Regards,
Garvin

[Don Chambers]

Thanks again Garvin. If we could still have a backend template option configuration screen, but save the options to a file instead of a db, how would it be less flexible? And for the record, I'm not trying to push for this change, because I think if you thought the idea was worthwhile, you would have already done it...

[garvinhicking]

Hi!

Thanks again Garvin. If we could still have a backend template option configuration screen, but save the options to a file instead of a db, how would it be less flexible?

Oh, you would have to code the whole storage mechanism! This would never be something that s9y would do on its own, only something you would maintain independently of s9y's framework.

The s9y framework for saving template options will stay inside a database, and will offer no PHP save alternative. This is too much overweight, less flexible, more painful and hard to maintain.

Best regards,
Garvin