Something we (at Widen) have found extremely useful is the ability to do some quick-and-dirty profiling of our production Tapestry applications when performance problems are actually happening. We wanted to make this tool available to multiple internal applications and decided to open-source it as well:
https://github.com/bdotte/tapestry-profiler So why tie a profiler to Tapestry? The fact that pages are always in a "pages" package, and that components are always in a "components" package makes organizing the data much easier. The tool will actually report time spent in each page separately (and spent in each job if you are using Quartz). One problem I typically have with profilers is that the stack traces for web applications get so large, it becomes a chore to sift through it all. tapestry-profiler lets you define your base application package, and ignores everything else in the results (by default). Hopefully this will be useful to others; we have not seen any noticeable overhead and we have used it frequently on large, busy production instances to track down issues that always seemed to elude us in the past. Comments or suggestions are welcome. Thanks, Ben
