I'm looking at the cache function in the findAll function of cfWheels. I'm a little apprehensive about using it. My queries are not taking that long that I absolutely need them, but a bit of a speed boost is always welcome. I'm getting 10ms from a queried cache that otherwise takes about 100ms. The thing I'm wondering about is when an entry changes, I'd like the cache to be cleared on the next run. It doesn't seem like there's any mechanism or flag in the framework that would allow that, so I'd have to set and clear the flags myself, which would most likely end up having to read from the database anyway. I was hoping that I could set the cache for a full day and update when needed, is this horribly misguided? I'm most likely not going to go down the road of developing any of the functionality to allow the caching for this application, but am curious if it is worth while revisiting.
More precisely whenever you make a new entry in the database, use the cfhttp tag to reload the application.
Caching can be cleared through reloading an application. It would not be the answer you are seeking but is a solution, here is an another approach. You can reload an application through <CFHTTP> by sending URL through <CFHTTP> after adding your new database record. If you are adding record through management site, then you can reload your Public site using <cfhttp>.
:)
Related
I have an application build in ColdFusion MVC framework "Mach-II" and hosted on blue dragon ColdFusion server.
It causes caching issue. When i added a new page with some contents and load the page than it's working fine. But when i made some changes in the same file and hit it again its not update my changes. Its always showing me the content that i have made in the very first time. Its seems like that the server is caching my page and did not consider further changes. I have tried many solutions but failed to solve the problem.
Please let me know if you have any solution for that.
This is a bit too long for a comment - but it's not much of an answer.
First off, your question is quite broad for StackOverflow. If you aren't looking at the code yourself, and have nothing to show us, there is no guarantee we can help you at all.
It sounds like maybe this service is using query caching - which looks something like this.
<cfquery datasource="CRM" name="testQuery" cachedwithin="#CreateTimeSpan(0,0,30,0)#">
-SQL logic-
</cfquery>
Basically it stores a query's result in memory on the server. It can really help reduce strain on the database. It's possible that they've set a time limit on this caching feature that's longer than you'd like.
If you don't have access to the code, THIS is the issue you want to ask about first.
Edit: It may be entirely different.
https://docs.oracle.com/cd/E13176_01/bluedragon/621/BlueDragon_621_WL_User_Guide.html#_Toc121303111
From source:
Where ColdFusion (5 and MX) defines a ‘template cache” as a place to
holds templates in memory once rendered from source code, BlueDragon
has the same notion but refers to this as the “file cache”. In both
engines, a template once rendered from source will remain in the cache
until the server (or J2EE or .NET web app) is restarted.
The cache size, specified in the Admin Console, indicates how many of
these cached templates to keep. It defaults to 60 but that number may
need to change for your application, depending on how many CFML
templates your application uses. One entry is used for each template
(CFM or CFC file) requested.
It’s very important to understand that this is not caching the OUTPUT
of the page but rather the rendering of the template from source into
its internal objects. One cached instance of the template is shared
among all users in the application.
As in ColdFusion, once the file cache is full (for instance, you set
it to 60 and 60 templates have been requested), then the next request
for a template not yet cached will force the engine to flush the
oldest (least recently used) entry in the cache to make room.
Naturally, if you set this file cache size too low, thrashing in the
cache could occur as room is made for files only to soon have the
flushed file requested again.
It sounds like you might have to either restart the ColdFusion application or clear the Template Cache in the CFAdmin.
I have an application that was built using Fusebox 4 with ColdFusion. Can anyone recommend a good caching solution, that is a plugin, which works directly with this older version of the framework?
Another idea I've been tinkering around with is to take the most commonly used queries in the system and applying cachedWithin. The value would be a variable stored in the application scope. Basically anytime we update any of the most commonly accessed tables in the db, we update the application.cachedwithin variable as well. So whenever these tables are updated the data is refreshed. Anything else that isn't used frequently will simply query the DB to get the content.
Also to add to this very simple caching methodology would be to simply store strings, or other frequently used content, directly within the application scope.
This bulk of this application is around 30 pages, comprised of approximately 200 products. So its quite a small website.
Can anyone recommend a good Fusebox 4 cache plugin or confirm if this simple caching methodology is a good idea? If not, could you recommend a simple alternative?
thanks in advance
I would suggest you to use cfcache to store all pages output into statistics HTML files.
Then on any update, you can clear the cache of the updated pages or all the cache:
<cfcache action="flush" />
<cfobjectcache action="clear" />
make sure to disable the urlSessionFormat() in URL.
I'm not sure that you even need to be caching given the size of the site, unless you are getting a huge amount of traffic. If you are currently having performance problems, the first thing to do is make sure that Fusebox is in production mode, so that it isn't recreating the parsed files on each request.
Caching the queries should certainly aid performance - how long are the queries currently taking to execute? With Fusebox 4, it can be problematic to have "Report execution times" turned on in CF when debugging, as it can significantly affect the time the request takes to execute.
I'm just started out with Ehcache, and it seems pretty good so far. I'm using it in a simplistic fashion to speed up reads against a database, but I wonder whether I can also use it to let the application stay up if the database is unavailable for short periods. (Update - my context is a application with high-availability modules that only read from the database)
It seems like I could do that by disabling expiry in the event of a database read problem, and re-enabling it when a read works again.
What do you think? Is that a reasonable approach or have I missed something? If it's a fair approach, any tips for how best to implement appreciated.
Update - ehcache supports a dynamically configurable option to un/set the cache to 'eternal'. This seems to do what I need.
Interesting question - usually, the answer would be "it depends".
Firstly, if you have database reliability problems, I'd invest time and energy in fixing them, rather than applying a bandaid solution.
Secondly, most applications need both reading and writing to work - it doesn't seem to make sense to keep your app up for reads only.
However, if your app has a genuine "read only" function, and there's a known and controlled reason for database down time (e.g. backups), then yes, you can use your cache to keep the application up and running while the database is down. I would do this by extending the cache periods, rather than trying to code specific edge cases. For instance, you might have a background process which checks whether the database is available and swaps in a different configuration file when there's trouble.
I have developed application using ZF.The app is little big with a lots of features.
I use Zend_Application(already using autoloader in constructor),Zend_Layout,Zend_view,Zend_form,etc. My current issue is, the page loading is very slow and that too in localhost with XAMP.
I have enabled xdebug, to investigate the issue, got a cachegrind file in "tmp" folder and tried to view it with WinCachegrind software. There i can a see a lot of processes and functions being run for each and every request or page load.
Also, i have installed YSlow add-on for firefox and observed the speed of page loads in seconds...I have compare the speed with ZF and non ZF applications. And from the comparison, the pages for non zf app takes less than 1 sec to load and for the ZF app, it takes atleast 6-7 seconds. What a huge difference.
Main Things happen in the app are :
1) Database connection happens for each request.
2) Im not adding the view to layout explicitly,ZF just appends it automatically, to layout.phtml, based on the action name.
3) Some windows have forms with few drop down boxes which fetches data from the database.
4) Have menus with ACL implimented, before it was loading the privilges from DB for each and every request, but now i have optimized it, so that it will work only duiring the login and rest of the time it will take from the Zend_Registry.
I would like to attach the cachegrind file so that some one can see whats happening in the background, but i cant see an option here for attaching.
Someone please help me to find a solution for this. Any kind of help is really appreciated. Thanks a lot
Let's try to give some hints.
First database connection should happen only once (except if you use several privileges access on the database or several databases). So check that you use Singleton patterns with you Zend_Db_Tables object
Then you do not use Zend_Cache. You should really start to use Zend_Cache and build several cache objects. Let's say for example a File cach, with long term storage, and a memcache or Apc Cache, storing objects. Then use these cache in several layers:
gives the FileCache to Zend_Db_Table (defaultMetaDataCache), this way you will avoid a loot of metadata queries, queries that ask for description of each columns of the tables you use.
Store one or more Acl object (depends on how you use Acl, if you have one big Acl with all rules or several with subsets). And store them in mid-duration caches when they are built.
Think of other usages, detect heavy loops, semi-static contents (like you select lists, how many time should they be considered static?)
Finally, get a whole mental image of how your application engine works, and how your data will grow and be used.You will need that step to use application levels caches in the very best way (for example should some elements be cached for groups of users?, should Acl objects be build for groups, for each user, for everybody, is ther some blocks in the layout that should be rendered the same for everybody?).
I am new to caching
What should I cache
eg. Do I cache user info? eg. since they are frequently used throughout the application (like in the header saying "welcome {username}")?
But most things should be used quite frequently anyways? eg. Users have projects. These projects don't belong to everyone, but they will be frequently used by specific users do I cache them too? Won't I be caching nearly everything then?
Also regarding CRUD, with doctrine queries, I can just use $query->useResultCache(true) but what happens when I update/delete an entity? I need to somehow update my cache too? how?
The basic principle of caching is to hold frequently used data that doesnt change often in memory to reduce database work.
Its more convenient to use the php session variables to hold basic things like username.
In case of projects, if they dont change often, and retrieved by users frequently, it would be a good idea to cache them. How long a project info stays cached depends on the change frequency.
Also note that if the info you present to users is vital or time important, you should use caching cautiously.
Check this reference page for basic information on caching http://www.doctrine-project.org/docs/orm/2.0/en/reference/dql-doctrine-query-language.html#cache-related-api
Or check http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html for detailed explanation.