I don't know about your tool, but when I was testing Tap3 and my app using JProfiler, I would pick a page, clear the stats and then submit a request. The time spent in each page is at the bottom of each page. Each page logs how long it took to render itself.
For one page: <!-- Render time: ~ 1190 ms --> And for another: <!-- Render time: ~ 209 ms --> However, that is a total time, what I wanted to know was what it was doing during each method call. And what JProfiler showed me was all of the method calls and how long each took. It even broke it down by each method. Ultimately, the individual method calls were too small to matter, but when you see calls to OGNL and the system spending 4000 ms. doing OGNL stuff, you realize it is better to minimize the use of OGNL. If your goal is to track just the time spent in Tap3, that can be done, but I don't think you will find that Tap3 is a cpu hog. To prove that to yourself, create some simple pages and profile those. Most of what Tapestry is doing is rendering your pages, which doesn't amount to much other than generating HTML and sending it back in a response. Which isn't much different than Apache sending back a file request. So, if anything is going to be slow, it is probably the application code that is being called to generate data to be rendered. HTH, Mark Mark J. Stang Senior Engineer/Architect office: +1 303.468.2900 mobile: +1 303.507.2833 Ping Identity -----Original Message----- From: Darío Vasconcelos [mailto:[EMAIL PROTECTED] Sent: Mon 10/9/2006 3:34 PM To: Tapestry users Subject: Re: Thoughts about performance monitoring in Tapestry 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]
