> I would suggest caching subparts of the page, rather than the whole page. > You can see a pattern for caching in > lift-mapper/src/main/scala/net/liftweb/mapper/ProtoTag.scala
I've been doing some reading - and I totally understand what your saying, and the use case for fragment caching is a strong one for the majority of applications. Rather than caching the final output of the entire page, how about this: Using the List[String] path of the requested template, before doing the database check I use the template path as a key in my cache, and return the cached version instead? This would certainly be a lot more granular than caching the whole page and still give me a decent level of improved performance. >I'd also > suggest caching pre-parsed XML rather than Strings. Sure, that was my bad - I actually mean XML, not the string of course. Id probably store the Can[NodeSeq] or whatever, so it can be directly returned from the cache with minimal processing. > I have a number of plans for Lift during RC including caching loaded > resources when in Production mode and some significant optimizations of the > render pipeline (so that there will be far fewer actual rewrites of the page > during rendering.) This should improve performance. > > When there's limited database access (e.g., a user lookup on each page), you > should able to serve 500+ pages/second on a dual Opteron. This is really interesting - I must admit, the whole Lift run modes is something that gets very little coverage: this sounds like it would be pretty sweet. Cheers David Tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
