One of the issues is that until we have a request, we don't know a number of things that Tapestry needs when constructing pages and supporting services. This really gets in the way of doing a "warm up". In the past, I've seen scripts that do a warm up against the server before the Apache reverse firewall is allowed to flood the server with requests.
On 4/24/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Yeah....It's probably ultimately something in javassist. It creates a very large cache of objects when compiling things. Not that it's javassists fault, there are ways to help fix some of that but it's not very straightforward / easy to do. ...Which more or less means intelligently finding ways to make it so that this cache can be cleared out. I've done this for the ognl compilations already but the method required to do it on tapestry proper will have to be much different so it's probably going to be a 4.2 kind of thing. (or maybe sooner if someone wants to take a crack at it, I'll happily outline my ideas somewhere ;) ) On 4/24/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > Hi Jesse, > > Thanks for your reply. I'll try bumping up MaxPermSize value - this > is one parameter that can possibly cause the crashes I am observing > (Xms/Xmx are sufficiently high already). > > Although I was still hoping there is a way to warm up the stack to > fill in the page cache before the app starts serving requests. But > looks like there's none? (if I can solve the JVM crashing, this > becomes a secondary concern, still would've been a nice performance > enhancement). > > Thanks > Andrus > > > On Apr 24, 2007, at 7:01 PM, Jesse Kuhnert wrote: > > > It's hard to say for sure what the problem is without more > > information but > > you can try adding things like the below methods to help your > > startup times: > > > > -) Increase or add the initial heap memory size via command line - > > Xms224m > > (or whatever seems appropriate) . > > > > -) Increase your perm gen space size - this will be critical for > > all of the > > javassist compilations that happen when initially loading up pages / > > components. -XX:MaxPermSize=99m > > > > -) Make sure you don't have caching disabled of course. ;) > > > > Not sure what else there is. I know there are a few unnecessary > > synchronized() lock calls in a few places that were added to fix > > some issues > > related to dev mode problems (ie caching being disabled) - but I've > > been > > slowly removing them here and there when I notice them. Maybe I > > should just > > do one big sweep of all usages to be sure. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
