Try JProfiler. It can track where you application is spending all of its time. One thing that came up earlier is that OGNL is a hog. However, we haven't found Tapestry to be the issue, but the rest of the app...
regards, Mark Mark J. Stang Senior Engineer/Architect office: +1 303.468.2900 mobile: +1 303.507.2833 Ping Identity -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Mon 10/9/2006 1:52 PM To: Tapestry users Subject: Re: Thoughts about performance monitoring in Tapestry Have you tried turning on Tapestry's "friendly URLs"? That would give you some better URLs to deal with maybe. > Hi, > > I'm currently analyzing an application built completely with Tapestry, > and additionally uses Spring, Hibernate, and EJBs. The main tool for > the performance analysis is an agent that is deployed in WebLogic and > reads HTTP requests, bean calls, and mostly everything that happens > inside the application (with, of course, a performance penalty while > the agent is on). > > But, obviously, there are only two main HTTP requests that show up in > the tool: a GET on /app_name/app, and POST on the same URL. Although > it is possible to analyze the request parameters, it would be very > hard to determine which pages are being called the most, which take > the most time to render, etc, without adding some kind of logging to > the app source, because most of the time the parameters, as all of you > know, are everything but friendly (the app is built with TP 3.0). > > So the tool really has a hard time trying to figure which requests are > the slowest, and the bean request tree is a huge list of all the beans > that are called from within Tapestry .java controllers, regardless of > the page. Since the app is using IoC through Spring, this makes it > even harder to figure which calls are being made at any specific > point. > > The tool does a fairly good job hooking itself to the app server and > its JVMs, so there's still a pretty large list of EJBs, SQL commands > and Spring services that might need to be looked at, because they can > take as much as 30 seconds to execute. But I'm hearing some voices > that speak "Hmm, maybe Tapestry is to blame here", since all requests > go through Tapestry's servlet and filter, and I have very few elements > to fight those voices. > > So I have several thoughts and questions, hoping that somebody will > shed some light on this: > > * Anyone knows of a tool that might be less request-oriented that > maybe even know how to interpret TP's parameters? > > * If small logging statements were to be added to the .java pages, > which would be the method(s) to add the logging to? pageBeginRender is > the obvious candidate here, but that would only take into account > rendering, without form submitting and component render cycles... > > * Is there a way to, through configuration, improve Tapestry's reading > of these kind of statistics? I'm thinking maybe friendly URLs, but > there might be other answers... > > * How to really determine how much time Tapestry is taking in doing > its job? For example, he tool is displaying a cumulative time of 4.61 > seconds for /app_name/app, but an "exclusive time" (meaning the time > that the method spends by itself, without the accessories) of 0.025 > seconds. Now that sounds great, but does it seem logical? I mean, > maybe some other components should be taken into account. > > * Anyone knows if Spring's methods to invoke and instantiate EJBs are > slow? The tool says that it can take as much as 2 seconds to do so!! > Maybe another place where traditional monitoring lacks? > > Regards, > > Dario > > -- > Some weasel took the cork out of my lunch. > -- W.C. Fields > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > James Carman, President Carman Consulting, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
