You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Darío Vasconcelos <da...@gmail.com> on 2006/10/09 19:20:54 UTC
Thoughts about performance monitoring in Tapestry
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Re: Customizing the Shell Component
Posted by Mark Stang <ms...@pingidentity.com>.
Dennis,
Thanks, I will give it a shot.
regards,
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
-----Original Message-----
From: news on behalf of Dennis Sinelnikov
Sent: Sun 10/15/2006 10:30 AM
To: users@tapestry.apache.org
Subject: Re: Customizing the Shell Component
Mark Stang wrote:
> Hi,
> I am using Tapestry 3.x and wondering how to customize my .css file with the Shell component. I want to be able to swap out my Shell component by putting it inside of a Library. If I do that can I still just reference it in my .html? I don't know why I think it is any different from any other component. Or maybe because I haven't tried to put a embed a Shell in my own component and put that within a Library. Then re-use it as needed. Does that sound doable?
>
> thanks,
>
> Mark
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
If I understand you correctly, you can declare your css stylesheet as a
context asset, this will enable you to pull your css file from you
library at runtime.
Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Customizing the Shell Component
Posted by Dennis Sinelnikov <de...@augustschell.com>.
Mark Stang wrote:
> Hi,
> I am using Tapestry 3.x and wondering how to customize my .css file with the Shell component. I want to be able to swap out my Shell component by putting it inside of a Library. If I do that can I still just reference it in my .html? I don't know why I think it is any different from any other component. Or maybe because I haven't tried to put a embed a Shell in my own component and put that within a Library. Then re-use it as needed. Does that sound doable?
>
> thanks,
>
> Mark
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
If I understand you correctly, you can declare your css stylesheet as a
context asset, this will enable you to pull your css file from you
library at runtime.
Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Customizing the Shell Component
Posted by Mark Stang <ms...@pingidentity.com>.
Hi,
I am using Tapestry 3.x and wondering how to customize my .css file with the Shell component. I want to be able to swap out my Shell component by putting it inside of a Library. If I do that can I still just reference it in my .html? I don't know why I think it is any different from any other component. Or maybe because I haven't tried to put a embed a Shell in my own component and put that within a Library. Then re-use it as needed. Does that sound doable?
thanks,
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
RE: Thoughts about performance monitoring in Tapestry
Posted by Mark Stang <ms...@pingidentity.com>.
Robin,
Great idea. If we migrate to 4.x, I will try it. I don't know what Howard is going to have available for 5.x, but I think it will support this.
regards,
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
-----Original Message-----
From: Robin Ericsson [mailto:lobbin@gmail.com]
Sent: Tue 10/10/2006 2:16 AM
To: Tapestry users
Subject: Re: Thoughts about performance monitoring in Tapestry
On 10/9/06, Mark Stang <ms...@pingidentity.com> 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...
For simple expressions, try tapestry-prop, which compiles into java
bytecode instead of reflection that ognl relies on.
http://howardlewisship.com/tapestry-javaforge/tapestry-prop/
--
regards,
Robin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Thoughts about performance monitoring in Tapestry
Posted by Robin Ericsson <lo...@gmail.com>.
On 10/9/06, Mark Stang <ms...@pingidentity.com> 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...
For simple expressions, try tapestry-prop, which compiles into java
bytecode instead of reflection that ognl relies on.
http://howardlewisship.com/tapestry-javaforge/tapestry-prop/
--
regards,
Robin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Thoughts about performance monitoring in Tapestry
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
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<da...@gmail.com>
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 <ms...@pingidentity.com>
> 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:james@carmanconsulting.com]
> > 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:
> users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail:
> users-help@tapestry.apache.org
> > >
> >
> >
> > James Carman, President
> > Carman Consulting, Inc.
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail:
> users-help@tapestry.apache.org
> >
> >
> >
> >
>
>
> --
> Some weasel took the cork out of my lunch.
> -- W.C. Fields
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail:
> users-help@tapestry.apache.org
>
>
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Thoughts about performance monitoring in Tapestry
Posted by Darío Vasconcelos <da...@gmail.com>.
Great replies!!
Konstantin,
creating a Filter is a good idea. I'll see if this can be implemented.
This tool I'm using is not really a profiler, but a complete solution
that hooks itself into the app server and monitors all method
invocation -with its correspondent times- into a database. For the app
I'm testing, I have more than 1,000 different method calls, although
only two main HTTP requests. There is a request tree that shows the
possible paths the requests have taken. And the times it is reporting
are pretty close to the users' perception: 5.5 seconds / average.
Mark,
you have a very good point about measuring each individual page; my
problem is that the app is already in production, there is no test
environment, and all measures were taken in one regular day -the
profiler slowed things very much-. Nevertheless, all method calls have
been logged, with call count, average cumulative time, avg exclusive
time, etc. This is very data since calls to Spring's
JdkDynamicAopProxy.invoke are taking as far as 2 seconds each! And
this is exclusive time, which means it doesn't take into account the
time inside the actual object that is being called...
My main issue here is that it needs to be proven that Tapestry is not
to blame for the slowness, and that having page information for the
request analyzer would be great...
Regards,
Dario
BTW, I cannot find information about JdkDynamicAopProxy being slow...
I'm not such an expert on Spring, anyone knows if this might be a
configuration issue?
On 10/9/06, Mark Stang <ms...@pingidentity.com> wrote:
> Well, then someone should change the text to say "shell rendering" time.
>
> Well, I hope his profiler shows the elapsed time for the method. Since there is are specific entry points he can profile those.
>
> Mark
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
>
>
> -----Original Message-----
> From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
> Sent: Mon 10/9/2006 4:21 PM
> To: Tapestry users
> Subject: RE: Thoughts about performance monitoring in Tapestry
>
>
>
> --- Mark Stang <ms...@pingidentity.com> wrote:
>
> > ....
> > 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,
>
> >....
>
> Please look up old discussions regarding those numbers
> on gname, in short: the numbers have nothing to do
> whatsoever with real rendering time.
> See for example Howard's post
> http://article.gmane.org/gmane.comp.java.tapestry.user/15280/match=render+time
>
>
>
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
--
Some weasel took the cork out of my lunch.
-- W.C. Fields
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Thoughts about performance monitoring in Tapestry
Posted by Mark Stang <ms...@pingidentity.com>.
Well, then someone should change the text to say "shell rendering" time.
Well, I hope his profiler shows the elapsed time for the method. Since there is are specific entry points he can profile those.
Mark
Mark J. Stang
Senior Engineer/Architect
office: +1 303.468.2900
mobile: +1 303.507.2833
Ping Identity
-----Original Message-----
From: Konstantin Ignatyev [mailto:kgignatyev@yahoo.com]
Sent: Mon 10/9/2006 4:21 PM
To: Tapestry users
Subject: RE: Thoughts about performance monitoring in Tapestry
--- Mark Stang <ms...@pingidentity.com> wrote:
> ....
> 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,
>....
Please look up old discussions regarding those numbers
on gname, in short: the numbers have nothing to do
whatsoever with real rendering time.
See for example Howard's post
http://article.gmane.org/gmane.comp.java.tapestry.user/15280/match=render+time
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Thoughts about performance monitoring in Tapestry
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
--- Mark Stang <ms...@pingidentity.com> wrote:
> ....
> 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,
>....
Please look up old discussions regarding those numbers
on gname, in short: the numbers have nothing to do
whatsoever with real rendering time.
See for example Howard's post
http://article.gmane.org/gmane.comp.java.tapestry.user/15280/match=render+time
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Thoughts about performance monitoring in Tapestry
Posted by Mark Stang <ms...@pingidentity.com>.
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:dario.vasconcelos@gmail.com]
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 <ms...@pingidentity.com> 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:james@carmanconsulting.com]
> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
> James Carman, President
> Carman Consulting, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
--
Some weasel took the cork out of my lunch.
-- W.C. Fields
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Thoughts about performance monitoring in Tapestry
Posted by Darío Vasconcelos <da...@gmail.com>.
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 <ms...@pingidentity.com> 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:james@carmanconsulting.com]
> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
> James Carman, President
> Carman Consulting, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
--
Some weasel took the cork out of my lunch.
-- W.C. Fields
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Thoughts about performance monitoring in Tapestry
Posted by Mark Stang <ms...@pingidentity.com>.
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:james@carmanconsulting.com]
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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Thoughts about performance monitoring in Tapestry
Posted by James Carman <ja...@carmanconsulting.com>.
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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org