I hope I'm not violating an NDA when I say that SeeSaw, the big UK video-on-demand Tapestry project, went down this path. They eventually turned off a huge amount of the features that, to me, make Tapestry special, including all dynamically generated JavaScript ... mostly to support more aggressive caching of full pages, or partial pages.
Anyway, at the end of the day, they found that they could have used Tapestry almost completely vanilla and it wouldn't have affected their throughput. Their problems were all elsewhere. Hopefully, Ben or Alfie is on the list to correct me if what I say is way off the mark. How are you identifying that rendering is your bottleneck? Just how much are you rendering? What tools are you using to gauge performance, and how are you identifying rendering vs. database access (when they can easily be mixed together)? There are a bunch of options out there, including progressive enhancement, that require much less re-architecting. You might find that the issue is database queries during rendering; I know you've mentioned caching is enabled, but that may not be enough. I'd look for ways to ensure that rendering is not held up by any database operations: - try to do all your db queries up front, and in parallel (tricky with Hibernate and SQL) - leverage caching - watch out for n+1 queries (via tripping over entity relationships) Finally, you may need to think in terms of a in-memory cacheable version of your data, optimized for quick access during rendering. That is, do your queries, and convert your entities into some form of simple DTO. I would even think that the DTO could be a collection of public fields (possibly, immutable public fields). Tapestry 5.3 is quite happy to treat a public field just like a property. The DTOs could contain just the data needed at render time, and could be denormalized, which is to say, roll data from relationships and/or inheritance, as much as possible, into a single object. On Sat, Jul 28, 2012 at 4:11 AM, Jens Breitenstein <mailingl...@j-b-s.de> wrote: > Hi T5'ers > > we have some performance issues and started thinking about caching our pages > (lets say parts of them to be precise). Due to the fact we are showing user > related information along with "public information" on a page, we can not > make use of a simple web proxy caching. > > Therefore we are thinking about a "component rendering result cache". > > Assume we have several independent components to show an overview of items > (and we have a lot of items rendered in a loop) and we want to cache the > rendering result of one of these particular components for several seconds > before rendering it again (to reflect new items or changes). I am aware this > means we are showing stale data for some seconds, but honestly this is not > an issue because after rendering and displaying it in the browser data is > considerably old anyway :-) > > What might be a good place to intercept the rendering and store the output > from a component and on the other hand use outputraw for sending cached > data? > Does anyone tried this before? > > Any idea or comment is appreciated, thanks in advance > > > Jens > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
