Please see some thoughts here http://article.gmane.org/gmane.comp.java.tapestry.user/29047/match=performance+tapestry
and note that for example Tomcat's log valve can be configured to include request and session parameters in the output, it means that the valve can produce fake url's which will include page and asset names in the url. That would make such log much friendlier for log analyzers. --- Darío VVasconcelos<[EMAIL PROTECTED]> wrote: > Well, actually the tool that I'm using (PerformaSure > by Quest) is > pretty professional, I guess I'm getting as many > clues as possible. My > questions were more in the direction of, How to > modify the source in > order to find out the time spent in each page, and > What are your > thoughts about this issue with Tapestry 3 being too > hard for these > kind of tools, since they're request-oriented. > > BTW, friendly URLs is not an option since I'm using > TP3. I'm also not > the owner of this app, so big configuration changes > is not an option > either. > > Regards, > > On 10/9/06, Mark Stang <[EMAIL PROTECTED]> > wrote: > > 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] > > > > > > > > > > > -- > 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] > > Konstantin Ignatyev PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
