At 11:41 AM -0400 4/14/2000, Sharon DiOrio wrote:
>What you're talking about is not really session related queries. Basically
>people are performing the same queries (as they drill down) and using
>"cached within/after" works here.
Yes, in effect it is site caching
> But what if you had a search function
>that let users make a custom search by keyword on the database? Using the
>"cached within/after" functionality would add this to the *limited* list of
>available cached queries that the system had in memory. Why? The user is
>only going to need the information for the duration of a session anyway.
>Why not just toss it when he/she is done rather than waiting for it to fall
>off the cached query list.
There *are* queries in the sites that *do* allow very specific,
keyword searches... no attempt was made to cache these as it would
unnecessarily clutter the "site" cache.
However, it probably *does* make sense to session cache these (on the
assumption that the visitor will make related/repeated queries)
>
>Also, CF has a limit of 100 cached queries (they may have changed this
>limit). When it hits this limit, it drops the last one off the list. If
>you're hosting multiple applications on a single server, using query
>caching could rapidly reach that limit and you run the risk of making CF
>work harder to manage the queries.
I don't own the server - my CF host does. So we share the server
with many other sites. However, I have done some elapsed timings and
site caching does (usually) improve performance. Shhh... maybe we're
the only ones using caching.
Also, it might be nice to have an option in CF server to allocate
query cache space to domains, etc.
>I'm not criticizing the choice to user CF's built-in query caching, only
>offering your another possible option for future projects. Let's look at
>your list below. If this data only changes minimally, I would have these
>queries saved into APPLICATION scope, and put the refresh on the update
>page.
I considered this, but decided that it would be rather expensive to
cache all the queries, and quite difficult to develop an intelligent
caching mechanism
> That way the query stays specifically as long as you need it.
>Actually, I'd be more likely to have an APPLICATION scope structure built
>from the query that allowed me to drill down to whatever information I want
>without hitting the DB at all, but that's another e-mail entirely.
Yes... and the other extreme would be to dynamically regenerate any
static pages affected by a given change... also yields no caching, no
db hits.
>
>Sharon
Thanks, for your input... you have given some great ideas that we
will consider as the sites evolve.
Dick
>At 05:37 AM 4/14/2000 -0700, Dick Applebaum wrote:
>>Consider this, then:
>>
>>A client's site (actually there are 6 similar sites with a shared db)
>>consists of products and supplier tables for an industry.
>>
>> 3,000 suppliers
>>
>> 1,000 products
>>
>> 30,000 products and suppliers
>>
>>There are only a few updates/inserts to these records on a daily basis .
>>
>>Site visitors will query the db looking for products and suppliers
>>
>>We use a drill-down as follows:
>>
>> Major Product group based on first letter of Product Name
>>
>> A-C D-H H-K ...............
>>
>> Alpha List of Product Names/links within a letter group
>>
>> Alpha List Of Companies Names/links which sell the product
>>
>> Detail Listing for a specific Company
>>
>>The way we use caching is this:
>>
>> Use An Application variable for each table denotes when that table
>> was lasted updated (set by db maintenance program)
>>
>> Each query against a table specifies CachedAfter using the above variable
>> (the youngest of appropriate table variables is used un the case
>>of joins).
>>
>>So, we are letting CF cache the queries for the system.
>>
>>The system seems to tune itself as patterns of usage emerge... I
>>assume that CF purges the least-recently-used (or some such) queries
> >from the cache.
> >
> >
> >The site performs well, in most cases better than a prior site that
> >used dynamically-generated static pages for the drill-down (there
>>were thousands of pages... now we have a few templates).
>>
>>
>>I am open to suggestions, but, for this situation, this appears to
>>be a better approach than session-caching the queries.
>>
>>
>>
>>You can see examples of this at:
>>
>> http://www.roadsbridges.com/
>>
>> http://www.seedworld.com/
>>
>> http://www.waterinfocenter.com/
>>
>>TIA
>>
>>Dyck
>>
>>
>>At 7:58 AM -0400 4/14/2000, [EMAIL PROTECTED] wrote:
>>>Absolutely not (on the optimizing one user question.) CachedWithin and
>>>CachedAfter are used for queries that require an expiration date. If you've
>>>got data that will need to be updated on a schedule, I'm all for it.
>>>However- if your data is something like, oh say a list of US States used for
>>>dropdowns throughout the system, why add the overhead of a datecompare to
>>>the server (which I assume would be done on each request for the query.)
>>>
>>>Another thing to keep in mind is that if the data is SESSION SPECIFIC, i.e.
> >>a user's permissions or something along those lines, how would you use
>>>CachedWithin? There's no way to tell in advance when the session will end!
>>>By using Session scoped queries, you let ColdFusion do it's cleanup work for
>>>that data just as it does for all other session specific data.
>>>
>>>I think the latter point is more relevant than the first, but that just's my
>>>opinion. ;-)
>>>
>>>Jason
>>>
>>>-----Original Message-----
>>>From: Dick Applebaum [mailto:[EMAIL PROTECTED]]
>>>Sent: Friday, April 14, 2000 7:43 AM
>>>To: [EMAIL PROTECTED]
>>>Cc: [EMAIL PROTECTED]
>>>Subject: RE: Query Caching
>>>
>>>
>>>A little different twist on this thread.
>>>
>>>Several people have suggested caching queries using session variables:
>>>
>>> <cfquery name="Session.myQuery">
>>>
>>>I can see cases where this would be useful, but I wonder if it is a
>>>good practice.
>>>
>>>Wouldn't be better to use the more general "CachedWithin or
>>>CachedAfter" parameters on the Query statement?
>>>
>>>It is my understanding that CF performs some magic with this format,
>>>and can efficiently cache queries for multiple users... actually, the
>>>entire system.
>>>
>>>By doing session caching, don't we run the risk of optimizing one
>>>user at the expense of the rest of the system?
>>>
>>>TIA
>>>
>>>Dick
>>>
>>>
>>>At 6:39 AM -0400 4/14/2000, [EMAIL PROTECTED] wrote:
>>>>Emily-
>>>>
>>>>It's quite possible to declare a query directly into any of the scope's
>>>>available to your application except Client (unless of course you serialize
>>>>the query w/ wddx.) This is a valid call:
>>>>
>>>><cfquery name="Session.myQuery">
>>>>
>>>>Resulting in Session.myQuery being cached for the duration of the session.
>>>>
>>>>-----Original Message-----
>>>>From: Emily B. Kim [mailto:[EMAIL PROTECTED]]
>>>>Sent: Thursday, April 13, 2000 12:05 PM
>>>>To: [EMAIL PROTECTED]
>>>>Subject: Re: Query Caching
>>> >
>>>>
>>>>>Is it possible to cache a query only for a particular user for only the
>>>>>length of his or her session?
>>>>>I have a query that generates a roles & privileges packet that applies
>>>only
>>>>>to the current session and user. When the session expires so does the
>>>>cached
>>>>>query.
>>>>>What the memory load differences vs. storing a session variable with a
>>>WDDX
>>>>>packet in it?
>>>>
>>>>you would have to write the query to an array and then store it in a
>>>>session variable. but you could also write the query results to a wddx
>>>>packet and write that to a session variable. i don't know that there would
>>>>be more overhead one way or another...? -emily
>>>>---------------------------------------------------------------------------
>>>-
>>>>--
>>>>Archives: http://www.eGroups.com/list/cf-talk
>>>>To Unsubscribe visit
>>>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
>>>>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>>>>the body.
>>>>---------------------------------------------------------------------------
>>>---
>>>>Archives: http://www.eGroups.com/list/cf-talk
> >>>To Unsubscribe visit
>>>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>>>>k or send a message to [EMAIL PROTECTED] with
>>>>'unsubscribe' in the body.
>>>
>>>----------------------------------------------------------------------------
>>>--
>>>Archives: http://www.eGroups.com/list/cf-talk
>>>To Unsubscribe visit
>>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
>>>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>>>the body.
>>>--------------------------------------------------------------------------
>----
>>>Archives: http://www.eGroups.com/list/cf-talk
>>>To Unsubscribe visit
>>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>>>k or send a message to [EMAIL PROTECTED] with
>>>'unsubscribe' in the body.
>>
>>--------------------------------------------------------------------
>>----------
>>Archives: http://www.eGroups.com/list/cf-talk
>>To Unsubscribe visit
>>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
>>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> >the body.
>
>
>------------------------------------------------------------------------------
>Archives: http://www.eGroups.com/list/cf-talk
>To Unsubscribe visit
>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>k or send a message to [EMAIL PROTECTED] with
>'unsubscribe' in the body.
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
