In case you forget this:
localhost:8000/yourapp/appadmin/ccache
this page gives an overall stat about your cache
On Jul 23, 6:23pm, mdipierro wrote:
> correction
>
> cache.ram.storage['web2py_cache_statistics']['total_hits']
>
> counts total calls to cache function while
>
> cache.ram.stora
Ok I changed cache.ram, 0 to cache.ram, 3600 in the first query as
well - I'm assuming web2py knows when something is not in cache, and
has to be fetched from db. This makes the "misses" count remain static
(not incrementing), and results are correct as well.
On Jul 23, 3:28 pm, Adi wrote:
> Nu
Number of 'misses' is incrementing by one every time. This means cache
technique is not working?
On Jul 23, 3:23 pm, mdipierro wrote:
> correction
>
> cache.ram.storage['web2py_cache_statistics']['total_hits']
>
> counts total calls to cache function while
>
> cache.ram.storage['web2py_cache_
correction
cache.ram.storage['web2py_cache_statistics']['total_hits']
counts total calls to cache function while
cache.ram.storage['web2py_cache_statistics']['misses']
counts misses, i.e. result not found in cache and recomputed.
I guess you want to monitor the latter.
Massimo
On Jul 23,
cache.ram.storage['web2py_cache_statistics']['total_hits'] is a
counter and you can read its status before and after.
Mind it will be affected by other concurrent ptocesses.
On Jul 23, 5:09 am, Adi wrote:
> Seems to work. One last question - how can I check if a particular
> call hit the db or no
Seems to work. One last question - how can I check if a particular
call hit the db or not?
On Jul 23, 3:03 pm, Adi wrote:
> Great. That's what I was looking for - in memory filtering. Will try
> and let you know!
>
> On Jul 23, 3:02 pm, mdipierro wrote:
>
>
>
> > No because they two queries are
Great. That's what I was looking for - in memory filtering. Will try
and let you know!
On Jul 23, 3:02 pm, mdipierro wrote:
> No because they two queries are different. The second query will not
> find the cached results from the first and pull them again.
>
> You can do
>
> def index():
> vi
One caveat, make sure you do not cache a variable that depends on use
variable else you have a potential memory leak.
On Jul 23, 4:52 am, Adi wrote:
> Ok I'm going to bug you a little more till I understand this well
> enough :)
>
> there are two functions in controller:
> def index():
> # he
No because they two queries are different. The second query will not
find the cached results from the first and pull them again.
You can do
def index():
videos = db( myquery ).select(cache=(cache.ram,0)) # myquery is
across multiple tables, with joins.
def favorites():
fav_videos =db( myq
Ok I'm going to bug you a little more till I understand this well
enough :)
there are two functions in controller:
def index():
# here I will hit database because user first comes here
videos = db( myquery ).select(cache=(cache.ram,0)) # myquery is
across multiple tables, with joins.
def
You place
videos=db(db.video.id>0).select(cache=(cache.ram,0))
where you want the videos to be extracted from db.
videos=db(db.video.id>0).select(cache=(cache.ram,3600))
everywhere you need to get the list of videos.
On Jul 23, 4:38 am, Adi wrote:
> But where will I place this query, for
But where will I place this query, for "videos" to be accessible
everywhere else?
On Jul 23, 2:29 pm, mdipierro wrote:
> videos=db(db.video.id>0).select(cache=(cache.ram,3600))
>
> 3600 are seconds and it is the cache time. If you replace the value
> with 0, it will be re-computed.
>
> On Jul 23,
videos=db(db.video.id>0).select(cache=(cache.ram,3600))
3600 are seconds and it is the cache time. If you replace the value
with 0, it will be re-computed.
On Jul 23, 4:13 am, Adi wrote:
> Hi all,
>
> I have this use-case:
>
> There is a set of rows being queried from the database.
>
> videos=db
13 matches
Mail list logo
