[thesite] if anyones bored..

.jeff jeff at members.evolt.org
Tue Oct 23 19:48:54 CDT 2001


dan,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Daniel J. Cody
>
> > i should have been more specific.  the times i
> > mentioned i was seeing on t.e.o.
>
> oh, that makes sense then.. t.e.o uses our old
> production DB box, which is a ton slower, obviously,
> than our live DB box
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

yeah, i know.  this is good because it exposes the inefficiencies in our
code even more.  fix them on t.e.o. and the improvement will be that much
more on the w.e.o.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> i had tuned the blockfactor based on how fast it was
> pulling results from the *live* DB, not the test one.
> we shouldn't tune our test site up like that, cus it
> will slow our live site down.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

huh?  it was set at a blockfactor of 100.  i don't mean to call you a liar
(and i'm not), but a blockfactor at the max doesn't much look like a tuned
one.  know what i mean?  i'd be willing to bet that the results i was seeing
with various blockfactors would hold true on w.e.o. -- 10 being the better
number.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> and i remember seeing somewhere that the optimum
> MacroMedia Official Recommendation(tm) for blockfactor
> was something like a blockfactor of 10 for every 3.2k
> of data returned or something
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

according to this article by allaire, it's suggested that the average number
of rows returned should be what your blockfactor should be set to.  that
doesn't help us much since we're already over 700 records returned.

i've done more research about blockfactor and have located the following bit
of information:

  "Use BlockFactor with caution. You may (if your
   driver even supports BlockFactor) be able to
   significantly increase the speed of your queries
   by forcing the database to return many rows of
   data at a time instead of just one at a time (1
   is the default). Just remember to count the
   "bytes" for every column you are expecting to
   grab, add them together, and then see how many
   complete rows you can pull at once. Keep in mind
   that the maximum you are allowed at one time is
   32K (32,768 Bytes)."

http://cfhub.com/advanced/cfquery_tag/optimization.cfm

this would suggest that the blockfactor chosen is extremely critical.
rather than just setting it as high as it'll go, it should be tailored to
keep the amount of data coming across within the 32K limit.  have any
calculations handy that indicate how many rows on average that is?  if not
i'll be happy to do those calculations.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> oh, i was talking comfortable as in actually changing
> cold fusion code.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i think we need a show of hands rather than our ideas of how many people
that actually is.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> ? i'm not suggesting we start throwing anything out..jeez.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

ok, fair enough.  thanks for coming out and saying it directly.  the feeling
i was getting from your side of the conversation is that you were
considering tossing it out in favor of writing a php version.

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/






More information about the thesite mailing list