[thesite] if anyones bored..

.jeff jeff at members.evolt.org
Mon Oct 22 02:03:49 CDT 2001


dan,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Daniel J. Cody
>
> > i'm talking about the sidebar (which is built for
> > *every* page request) versus the main content area.
> > there are now a ton of queries necessary to render
> > any given page.  there are definitely some things
> > that could be done to improve this situation alone.
>
> for our major pages(article, front page) the majority
> of query rendering time isn't fromt the sidebar queries
> though(at most they take about 5-20ms a piece).
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

5-20ms a piece for a bunch of queries adds up quickly.

at my count, the execution times for queries and includes for the sidebar
total about 700-750 milliseconds.  that's longer than it needs to be.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> improving those queries wouldn't really improve the
> overall performance of the front or article pages..
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i agree in principle.  if you've got a front page that takes about 8000-9000
milliseconds to execute, cutting a couple hundred milliseconds from the
overall processing time won't really make much of a difference.  however,
it's this sort of thinking that has caused the entire site to slow down so
much.  for example, why is it taking over 7000 milliseconds to join 3
relatively small tables and return a query resultset just over 700?  that's
absolutely ridiculous.  solve that and you've solved 90% of the time wasted
rendering the homepage.  here's a question, if we're only showing ten rows
at a time on the homepage, why is the blockfactor so high?  also, why isn't
that homepage query cached so we're not running it *every* time someone
navigates to the next n results?

just as an example, using the cachedwithin attribute of the <cfquery> tag
that pulls the articles for the homepage reduced the processing time to just
over 1000 milliseconds.  that seems to be a much more realistic time.
something really needs to be done about that query though with regard to the
initial hit which will still take a long time for visitors to the site when
there isn't a version of that specific sql in cache.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> on the outside, that seems like a good call. i was
> talking toa  couple people tonite while watching the
> packer game(doh. :( ) and alot of the things we 'hacked'
> in CF to get the SSURL scheme working(for example)
> would be an easy thing to do with PHP, like d.e.o. we
> had to pull a lot of cool, funky hacks to get that
> working with CF. its actually pretty easy to do that
> specific feature with a more open language though like
> PHP. thats just one example btw :)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

and?  what we knew at the time when the foundation for v2 was developed
involved these hacks you mention.  and there's not "a lot" of them, only a
few.  knowing what i know now about how to accomplish the same thing does
*not* require the sort of hacks you're referring to (not anymore than is
required in php anyway).  however, that's a moot point cause the hacks you
mention aren't where the inefficiencies in the site are.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> well if it produced the same results, whats the big
> deal? we wouldn't need or probably want a
> alphaboxcontroller.cfm file serving everything just to
> get SSURLS. if we could get similar results without all
> the hacks, thats a good thing, no?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

first of all, these hacks you keep referring to are no longer necessary with
what i've learned about implementing sites using directory-style query
strings.  since the architecture i put in place which required the
alphaboxcontroller.cfm file was never used properly, there's really no need
to keep using that file.

so, what i'm saying is we can get the same results we're getting now (albeit
more efficiently) without the hacks and still use coldfusion.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> it may not help people understand it if it were in a
> different language, but the fact is, there are a lot
> more people that know PHP here. also, as explained
> above, it wouldn't take hardcore hacks with a language
> like PHP to achieve the same results.. the PHP arch.
> wouldn't have to be *SO* complicated. because of that,
> more people - with an intermediate knowledge of PHP -
> would understand it and could make contributions
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

ok, now they're hardcore hacks.  i give up.

you talk about the complication of the architecture.  this actually has very
little to do with using directory-style urls.  it's designed so that it's
highly modular and can be worked on by multiple people without stepping on
each others toes.  it's also designed to afford multiple types of displays
of the same content very easily.  doing so creates complexity in the
architecture.  you're not going to get away from this in php unless you
either (purposely?) don't take these things into account when building it or
introduce lots of redundant code into the application making it very
difficult to maintain/update.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > sorry to say, but changing languages won't make it
> > easier for more people to understand.  it will only
> > change the group of "experts" that are comfortable
> > making changes to the application.
>
> no, it won't make it easier for everyone to
> understand. the point is the group of experts
> would expand beyond 2 people.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i didn't use the word "everyone".  i said "more people".  beyond 2 eh?  i
don't even know what to say to that it's so silly.  there are most
definitely more than 2 people on this list that have some degree of comfort
with working with the cf source code.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > as for limitations of the current architecture, there
> > have been a ton of things learned about this
> > architecture since we built this version of the cms
> > about a year ago.  there are also a bunch of
> > efficiencies we can take advantage of in cf 5.0.
> > additionally, there are things about the cms that we
> > understand much better now and could change in it to
> > make it more efficient.
>
> what what and what? :)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

well, for starters, we could use a user-defined function to perform the
tasks of the uta custom tag.  we could do the same for the pageresults
custom tag.  we could be a crapload more careful about how we read/write
session variables.  we could get more vigilant about the queries that are
run on the site, caching as many as possible.

just as an experiment i went through application.cfm, the homepage
application, and the includes in the sidebar and took a look at making
everything more efficient without removing any of the existing
functionality.  by keeping the number of queries that are run to a bare
minimum (yes there were several instances where there were queries being run
for absolutely no reason or being run to keep errors from occurring when the
logic surrounding the bit of display that was error needed to be corrected
instead), caching as many of the queries as was practical, and a few other
tweaks and i was able to cut the processing time for the homepage by
***95%***.  it's now from an average of 8000-9000 milliseconds down to about
450 milliseconds on all but the initial request (when no queries are
currently in memory).  maybe i'm biased, but i'd say that's a huge
improvement.

don't go trashing the application server because it's not as fast as you'd
like when there's *lots* of room for improvement in the code.

thanks,

.jeff

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






More information about the thesite mailing list