View previous topic :: View next topic |
Author |
Message |
bsmith Smarty Rookie
Joined: 29 May 2003 Posts: 11
|
Posted: Mon Jun 23, 2003 4:54 pm Post subject: How often should i use clear_compiled_tpl |
|
|
Anyone have a suggestion as to how often to call clear_compiled_tpl? Not sure of the performance impact to the user that hits a page with this call.
Should I create some automated too that call it using wget or something.
I would like to know how others are doing this.
Thanks,
Brian |
|
Back to top |
|
idxman01 Smarty Rookie
Joined: 10 Jun 2003 Posts: 14 Location: FL
|
Posted: Mon Jun 23, 2003 10:05 pm Post subject: |
|
|
If you have $compile_check on, then it'll recompile it automatically. Otherwise, only call it if you changed a template.
-r |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Mon Jun 23, 2003 11:49 pm Post subject: |
|
|
?? only as often as required, preferably never on a production site.
It is NOT a tuning feature. It is a maintenance feature which works as idxman01 indicates. |
|
Back to top |
|
bsmith Smarty Rookie
Joined: 29 May 2003 Posts: 11
|
Posted: Tue Jun 24, 2003 8:33 pm Post subject: Not sure I understand then |
|
|
What I would like to do is manage the growing list of sub-directoreis under templates_c directory, do I need to "clean these out" by hand, or will the list keep growing indefinitely?
Maybe I'm not using compile_check correctly. Even in a production application, templates will eventually get changed when new features are added or design changes are desired. When this happens, do I turn on compile_check for a while, then turn it back off once the changes are re-compiled?
Please help if you can.
Brian |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Tue Jun 24, 2003 8:43 pm Post subject: |
|
|
why? Those are Smarty working files. They aren't meant to be managed other than for the needs of your application.
As for your question regarding turning on/off the compile check, I'd say yes: if you know before hand when it is appropriate to turn off/on, then do so. Typically, I keep different setting for my different environments:
1) production -- speed! no compile check, caching where possible.
2) testing -- same as production
3) development -- compile check, no caching, debug console
because of the design of my site, I typically just wipe out my temporary directories when I am doing a site update to ensure that everything is recompiled and cached properly.
HTH |
|
Back to top |
|
bsmith Smarty Rookie
Joined: 29 May 2003 Posts: 11
|
Posted: Tue Jun 24, 2003 9:39 pm Post subject: can you share with me how you do your setup? |
|
|
How do you wipe out your temporary files? Here is how I have my setup
root (public html)
-member (private app area)
--classes
--templates
--templates_c
That's about it, all my templates are in the templates directory, and I keep out browsers using my apache config. Smarty creates all compiled subs under templates_c by default I guess.
What do you do when you post new code/templates to your production site?
(all this is helping a lot, I appreciate it).
TIA,
Brian |
|
Back to top |
|
messju Administrator
Joined: 16 Apr 2003 Posts: 3336 Location: Oldenburg, Germany
|
Posted: Tue Jun 24, 2003 10:26 pm Post subject: |
|
|
see
http://smarty.php.net/manual/en/api.clear.compiled.tpl.php
on how to clear them smarty-wise.
in a perfect world you don't have to worry about them, they get recompiled (and rewritten) when a template changes. this "changes" should imply an upload of any template to your production site. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Tue Jun 24, 2003 10:51 pm Post subject: |
|
|
As messju kindly points out, there are programmatic controls available.
What I do is slightly different. My compile and cache directories are stored as sub-directories of a single directory (let's say, tmp) and I physically destroy tmp when I do a site refresh. That is not always desirable or necessary, though. Like anything worth considering, it depends on your context and what you are trying to achieve. Never-the-less, unless you have specific application logic that is dependant on the existance of your compile/cache files (which is extrememly unlikely), there is no harm in my approach what-so-ever. At WORST, your site will temporarily slow down as Smarty re-compiles templates and re-caches content.
I consider these things a maintenance issue and so I don't have code in my application to deal with them--instead I have maintenance scripts that handle those chores for me outside the confines of the application. I'm a little too old to be doing everything by the seat of my pants, I'm afraid
The key: most of the settings that were discussed earlier are set-and-forget. You typically only need to (temporarily) change them when a physical change actually occurs to your templates and or application. In other words, this is a fairly mundane topic If you still have questions, please consider posting a more specific example.
Take care and have fun!
xo boots |
|
Back to top |
|
bsmith Smarty Rookie
Joined: 29 May 2003 Posts: 11
|
Posted: Wed Jun 25, 2003 8:45 pm Post subject: Thanks, I think I have it |
|
|
I think I understand, and i, like you, have created tools that clean up directories/tables/files running as cron jobs.
Don't compile check (for speed)
Get rid of compile and cache to cause an application to re-compile and re-cache
That's basically it, and what I'm going to do.
Thanks so much for the help.
Brian |
|
Back to top |
|
idxman01 Smarty Rookie
Joined: 10 Jun 2003 Posts: 14 Location: FL
|
Posted: Thu Jul 03, 2003 5:12 am Post subject: Re: Thanks, I think I have it |
|
|
bsmith wrote: | Don't compile check (for speed)
Get rid of compile and cache to cause an application to re-compile and re-cache
|
More or less.. but as always it depends on the app. You may not necessarily need to get rid of _all_ the compiled tpl/cache. eg: one template changes, but its not recompiled (nor cached) until you either delete the tpl/cache or turn compile_check on for the time being..
One thing I've done that helps is to [as mentioned] use the API, so I can setup some admin `clear cache` and `clear tpl` links for myself. (non-CLI situations) The other handy thing is to add app logic to clear the cache when necessary. eg: When you know a specific action will change the data, clear it (certain cache groups in my case), so the next page view will auto-regenerate it for you.
-r |
|
Back to top |
|
|