You can cache the content of each widget by query caching or fragment caching. And also the page caching will do a great job, if the news are not so frequently updated compared to the page views.
The query caching uses SQL string (or precisely saying the hash of it) as the key to the entry. For example, the results of the following 2 SQLs will be cached into the separated entries.
1. SELECT * from table where some_field like '%yii%'
2. SELECT * from table where some_field like '%php%'
When 2 of your widgets uses exactly the same SQL, then they will share the same cache entry. But if there are any difference between the 2 SQLs, no matter how small the difference might be, they will be cached as the different entries.
Well, I don’t get precisely what you mean by “Array” in your first post, but I don’t think it’s a good idea to cache some range of db records for generic purpose and loop through it to get each result sets for individual widgets.
i ask you make post in wiki for best caching techniques to make performance higher and suggest where to fragment caching , query caching and all type of caching
I also advise you to carefully check your ‘cache dependency’ conditions, and/or set ones. Not thinking in advance on those issues can lead to hard to find bugs. It all depends on your exact requirements, BTW.
Information on ‘cache dependency’ and expiration setting can be found in the link given above by softark to the official documentation.
If you haven’t defined any dependency, then cache will remain the same … the outdated content will continue to be served from the cache. So we usually define some dependency to invalidate the cache entry if something has changed in the relevant tables.
Just as Boaz said, the settings of expiration and dependency are the critical path. Please refer to the official documentation for details.
