On Wed, Mar 24, 2010 at 3:26 AM, Martin Sachs <sachs.mar...@gmail.com>wrote:
> hi, > > we need caching of components, since the construction of huge > hierarchies is not cheap. The rendering ist fast. We cache the rendered > HTML of a hole component via a beheaviour and write them on the next > requests into a Label (unescaped). So instead of creating the complete > hierarchie on every request, we create a much smaller one. But you must > check, that the cachable components are stateless. Also we have JQuery > for client-effects in this components, this would also be cached. > > The performance is much better with that: approx. 10-50 times better: > 100ms with cache (the response time is not much depending on count > of users) > vs > 1500 ms without cache depending how many parallel user > A 15x gain is a big statement to make. Can you please break this 1500ms down into at least the following categories: 1 - time in IModel#getObject() and all child calls of this (IOW, loading data) 2 - time in constructor of components (without loading data in the constructor - hopefully you're not doing this) 3 - time in rendering of components That would be a much better number to give other users. I have NEVER seen where creating / rendering components could take 1400ms - unless you're doing something wrong like database calls in your component constructors. So, I suspect that most of that 1400ms (I would guess at least 1250ms) is in your model loading. The only time I've seen (or seen proof of) the component hierarchy actually be the slow part of a Wicket page is if you were displaying a repeating view of some sort with thousands of rows and each row had a bunch of components in it - leading to tens of thousands of components being built in the hierarchy. -- Jeremy Thomerson http://www.wickettraining.com
