> The benefits listed below diminishes if application operates under a load
> balanced environment since it's very hard to synchronize large cached
> queries or, any cached query for that matter, between servers. You can
call
> all other servers when one is being updated but performance wise not a
good
> idea unless you are getting huge returns.
I disagree. If you set up your clustered envirtonment correctly, you should
have all the server flush their cache when the database is updated or at a
scheduled time. What we have done is actually have one server just run as
the "commander" as we call it. When we make a site wide update, we have
"the commander" send out to the other servers script commands to run (based
on what it is we want them all to do). I don't see how this is
"performancely wise" this isn't a good idea. If you don't keep all your
servers exactly the same, then data corruption can occur.
--=@ greg @=--
----- Original Message -----
From: "Xing Li" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Friday, February 02, 2001 3:54 PM
Subject: Re: The BETA IS OUT!!! (query a query)
> The benefits listed below diminishes if application operates under a load
> balanced environment since it's very hard to synchronize large cached
> queries or, any cached query for that matter, between servers. You can
call
> all other servers when one is being updated but performance wise not a
good
> idea unless you are getting huge returns.
>
> If you cache a product description and that product description is updated
> but since each of the 3 clustered servers are holding a different cache
you
> might have a public relations nightmare if those orders are placed based
on
> an out-of-date description.
>
> xing
>
> ----- Original Message -----
> From: "Jennifer" <[EMAIL PROTECTED]>
> To: "CF-Talk" <[EMAIL PROTECTED]>
> Sent: Friday, February 02, 2001 9:45 AM
> Subject: Re: The BETA IS OUT!!! (query a query)
>
>
> > We have cached queries that hold information that is used on every page
> hit
> > of the site. Every page returns a random record from the cached record
> set.
> > Now, each of these records have links to products, and each record has
> > several products associated with it. Ordinarily, the first link is
> > displayed. However, in one section of the site, all of the products are
> > displayed (sometimes these are recipe ingredients so let's assume that's
> > the case). Below the section that lists the products is a section that
has
> > links to all recipes that contain that product.
> >
> > Now then (what does that phrase mean anyway?), I have cached queries
that
> > contain the recipes and the associated products but the query is run on
> the
> > recipe id. However, to get the list of all recipes that contain a
> specified
> > product, I'd have to use a significantly different query but one that
> > contains all of the same fields, joined in a similar way. The only thing
> > that changes is the search criteria: you are either searching by recipe
id
> > or you are searching by product id. In both cases, a lot of the same
> > information is returned.
> >
> > Right now, this sucks.
> >
> > However, if I could load in a query of all recipe ids joined on the
> product
> > ids and another list of the copy for the recipes joined on their recipe
id
> > (including the first product id), I could do this instead:
> > 1) display the copy linked to the recipe id where that needs to happen
> > (every page of the site) by outputting a random record from the
> copy/recipe
> > id set
> > 2) generate the list of ingredients by querying the recipe id/product id
> > list for that recipe id
> > 3) generate the list of recipes by querying the recipe id/product id
list
> > for the product id
> >
> > That means that instead of caching 100 recipe id/product id queries plus
> > 500 product id/recipe id queries (or hitting the db every time or
loading
> > the records into a structure), I could cache 2 queries and query them as
> > appropriate. It would be much simpler and would save resources lost to
all
> > other methods.
> >
> > Ding ding ding!
> >
> > At 03:09 PM 2/1/01 -0800, you wrote:
> > >I haven't thought of a kickass problem/solution that would need query a
> > >query ability so I'm happy that's it is there to use but not, stoked,
at
> > >least not yet. =)
> > >
> > >Have not tested or even had the priv to touch 5.0 yet but isn't just
> query a
> > >query just a search option? So we can do a search for array values,
> structs,
> > >and now arrays which are in a way structs. Hmm..actually, I have yet to
> use
> > >structfind() with queries so I wouldn't know if that works already.
> > >
> > >Maybe with query a query you can isolate a range of records that fits a
> new
> > >condition on a existing query? but wouldn't that be a waste of ram and
> sql
> > >power to return a large query in the first place that you need to do
sub
> > >queries on?
> > >
> > >Basically, I'm trying to find a good problem that would really need the
> > >feature and would speed up the performance while not wasting resources.
> > >
> > >Xing
> > >
> > >
> > > > So who's stoked about the Query a Query ability? Pretty damn cool
eh?
> > > >
> > > > Michael Buffington
> > > > [EMAIL PROTECTED]
> > > > (714) 556-3890 x222
> > > > http://www.price.com
> > >
> > >
> > >
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
