Smarty

[Frank]

Hello,

I have just finished developing a website based on the smarty template engine. First of all I want to give my compliments to the creators of this project. The way it works is really fantastic and offers a lot of oppertunities to work effectively.

There is only one point that concerns me:

Since we are using it our CPU load has increased. Nothing has changed on our server except that we are using Smarty. For example:

The total parsetime of a page is:

0.045

0.017 is PHP and the rest is Smarty rendering time.

My question is:

- Could it be Smarty causing our higher systemload?

If so:

- What can I do to make Smarty less systemintensive.

Thanks in advance

System information
Apache 1.3.29
Smarty 2.5 (stable)
PHP 4.3.4
Linux 2.4.22

[Troublegum]

You should try PHP Accelerator (http://www.php-accelerator.co.uk/)

[boots]

Asides from an accelerator, you will want to maximize smarty's cache usage. Whenever possible, you also want smarty to avoid recompiles. Of course, those are dependant on your application design.

[jkaufman]

"Asides from an accelerator, you will want to maximize smarty's cache usage. Whenever possible, you also want smarty to avoid recompiles. Of course, those are dependant on your application design."

Can you elaborate a bit on the "application design" part? What sort of design would be bad/good for caching?

I have what I think is a simple app with a simple design (being a simple person), but if I turn on Smarty caching, my app displays the incorrect record from the db.

[Page 1 of my app requests a record number. Since I needed to do this on more than one page of my application, I created a common template that displays a form requesting the input from either a select field or a text field. Page 2 uses the input value to retrieve a record from the db. If Smarty caching is on, I get the wrong record after the first one. Otherwise, I get the correct record.]

I am running Smarty 2.6.0-RC2 on a Mandrake 9.1 system.

[boots]

Hi jkaufman.

Application design is too complex for me to go into here, particularly with such a general question Never-the-less, I have some practical advice for you.

The problem you describe is common for those just starting with Smarty's caching. The issue is actually quite simple and easy to resolve: when you cache your template, the results from the first cache operation are "locked in"--subsequent calls to the template always get that first cached version.

What you need is to create separate caches (using cache_id) for the template. In your case, you'd probably base the cache_id on the query id. It is explained in the manual: Multiple Caches Per Page. One reason this isn't done automatically is to allow you to have full control over caching issues.

Better still, you can use the is_cached() (see also: example 14-4) function to see if a page already exists in the cache--that way you don't have to do any of your normal application work (not even smarty assigns)--you just simply display the page.

Performance should increase dramatically once you get the caching down.

[oschonrock]

Hi boots

We are using is_cached extensively to prevent application logic / db queries running. This does indeed have a very significant benefit.

However, because we have broken up our pages into many many components (up to 20 per page) and are calling is_cached for each of those, we found that this function itself is actually a bit of a bottleneck. On a 1Ghz unloaded server we are getting execution times of around 1ms for each call of is_cached. That's 20ms of overhead which we can't eliminate.

I was surprised to see this, so I had a bit of a look at that function. It seems to proceed down the call stack to _read_cache_file which reads the entire cache file in a php loop. This makes it not so surprising that the execution time is 1ms.

Is there a more efficient way to determine if a template is cached? Can we use a cache_handler somehow, to just read the first couple of lines of the cache_file and compare m_time etc? I saw your post here:
http://www.phpinsider.com/smarty-forum/viewtopic.php?t=1386&highlight=iscached+speed

but I am hoping we can do something a little more "standard" to speed up is_cached.

Thanks for your help

Oliver

[messju]

if is_cached() reads the cached file the subsequent fetch() or display() doesn't have to read it anymore. i may be short-sighted but i cannot image a single incidence where one wants to know if a page is_cached() but doesn't want to use the cached-contents afterwards (with fetch) . so you won't get anything if you avoid the read in is_cached() and do it in fetch() instead. all you get is a race-condition between the is_cached() and the corresponding fetch()-call if you don't read the cached-contents on the time of is_cached() already.

greetings
messju

[oschonrock]

Hi Messju

Thanks for quick reply.

Yeah, after thinking about that , and looking at the code some more i have to admit the full read of the cached file is unvoidable.

Guess we will have to live with that overhead or reduce the number or cached templates per page.

Cheers

Oliver

[boots]

This may or may not work for you, but you may want to look at this less-than-elegant strategy I proposed in an attempt to speed up a particular corner case of is_cached reads. More could be done, but it is a start if you are particularly concerned with such matters.