Performance tweaks

Isaac, 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 -- Marlon "And if I claim to be a wise man, it surely means that I don't know"

----- Excess quoted text cut - see Original Post for more ----- 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-6F16DE9D75 F02CDF 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.com http://coldfusion.sys-con.com/author/4806Dealey.htm