> I've been playing around with onTap for a couple of
> days now, but I'm starting to wonder about performance.
> In production mode, a simple page that has a database
> backed form (using the <tap:form tag) runs at 2.6
> seconds. I'm afraid that once I actually get some
> layout and navigation going, this page generation
> speed won't be bearable? Is there something else
> I should be doing other than setting
> request.tap.development = false and
> request.tap.compress = true?
> Thanks
Yep performance is an issue... although the framework appears to scale
rather well...
When Dave Ross put up his blog, the first article on it was about
load-testinbg comparisons between Fusebox, Mach-II and onTap which I
was doing at the time. I hadn't actually set up the web-stress tool
myself, Dave did it for me and got these results:
http://www.d-ross.org/index.cfm?objectid=9C65EF7D-508B-E116-6F16DE9D75F02CDF
The encouraging aspect being that although onTap did appear to be very
heavy (more than 2x the load time of Mach-II) for a smaller number of
threads (20) its performance improved to become near or better than
that of Mach-II at much higher numbers of threads (150). Although all
of this is somewhat outdated now as this was before the release of the
HTML libraries. Maybe one of these days I'll find some time to draw up
a simple test application to compare them again...
Regarding the HTML library specifically, I know that it's pretty heavy
when compared to a flat file (which is more work). There are some
caching tools built in to the html tag to help reduce some of this
load. Here's a brief example:
<cfmodule template="#request.tapi.xhtml()#"
cachedafter="#application.tap.appstart.time#"
cachename="myform" formvalues="#attributes#">
<tap:form>...</tap:form>
</cfmodule>
There are some limits to this -- one caveat in particular is that once
cached, the contents of dynamically generated select boxes, radio
buttons and checkboxes will also be cached (so if the content of the
table changes, you need to change the cachedafter date). The example
above won't change the cachedafter date when the content of a related
table is updated, although I'm thinking about adding the ability to
explicitly delete the cache using the tag, i.e. <cfmodule ...
cachename="myform" deletecache="true" /> and have it destroy the
cached form elements.
For forms you may want to stick with generating the form on each
request unless you have a specific need for a particular form to load
faster because of this limitation, however because navigation is
usually reasonably static it should be reasonably easy to create a
caching scheme for navigational elements that allows you to take full
advantage of the html libraries without suffering much delay. On the
framework site right now I believe I'm using
"header.#variables.tap.process#" as the cachename for the header
because each process might change the header by adding a sub-menu,
etc. The internal caching scheme in the html tag ensures that cache is
stored for each brand (if branding is enabled) and each locale (if
multiple languages/locales are used) so your own caching scheme
doesn't need to include these vectors. The generated output of html
structures (flat text) can also be separately cached at display to
further improve performance after adding customizations to the html -
there's a content.cfm custom tag (#request.tapi.content()#) or you can
simply store the string returned from html.show() into a shared scope
variable.
Additionally (and more generally) if you're not using or not planning
to use the framework's branding features, you can turn them off, which
will eliminate some loop cycles. I believe the variable for that is
request.tap.brand, so simply adding request.tap.brand = false to your
_appsettings.cfm should do that for you.
If you're not terribly concerned about having the most flexible
navigation possible, you can also use flat html in /_layout.cfm
templates to generate navigation. It's not as powerful or as easily
branded as html library navigation, but it's definately faster. Of
course you can also combine some elements of both. While the xhtml
custom tag is really nice for being easy for developers to read, it
introduces a lot more overhead than the cf_html library because it
needs an xml document which is then parsed and converted, whereas the
cf_html library functions are faster, but harder for developers to
grasp when reading them. A compromise for some navigation may be to
use a semi-static /_layout.cfm template where the larger elements are
static text and laid out with CSS while menus and other dynamic
navigational elements are generated with your own set of menu
management functions, i.e. mainMenuAdd(label,url) or
subMenuAdd(label,url).
As a side note, I don't recommend using /_layout.cfm templates for
plugin applications because they're harder to customize when someone
else installs your plugin. They'd have to either change your layout
template -- which is one of the cardinal sins I'm trying to avoid with
this framework -- or they'd have to use a branded /_layout.cfm
template which would replace yours if they need to change any
hard-coded text in it.
All that being said, of course any way that we can improve the
frameworks performance would generally be considered a positive
addition. :) Although it seems to scale well, performance has never
been its strongest suit -- it's always been much more about creating
powerful applications quickly than it has been about page delivery
(applications vs. sites).
I hope this helps clarify. :)
Let me know if I just made it all muddier. :)
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.comhttp://coldfusion.sys-con.com/author/4806Dealey.htm~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49Message:
http://www.houseoffusion.com/lists.cfm/link=i:42:1854Archives:
http://www.houseoffusion.com/cf_lists/threads.cfm/42Subscription:
http://www.houseoffusion.com/lists.cfm/link=s:42Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=17837.14401.42Donations & Support:
http://www.houseoffusion.com/tiny.cfm/54
