-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ragini,
On 9/17/12 8:55 AM, Ragini wrote:
> In the output, I have noticed that the main class which is
> responsible to execute jsp page is "Lorg/apache/jsp".
Your JSP files are translated into Java source files that use
"org.apache.jsp" as a prefix. So, if you have a JSP file found under
/my/jsps/SomeJSP.jsp, then you'll get a class called SomeJSP that
exists in the package org.apache.jsp.my.jsps.
> But I am not sure if there are also other classes which are
> responsible for this. I am curious to know this. In my profiler I
> have an option by which I can exclude classes which I dont want to
> profile.
Can you include classes based upon a package-name regular expression
(or prefix)? If so, just do this:
profiler.include.packages=org\.apache\.jsp\..*
or
profile.include.packages.prefix=org.apache.jsp.
> 1) Are the methods of org/apache/jsp class and time dependent?
Only your code goes in this package, so only you will know that.
I'm not even sure what "time dependent" means. Do you mean
non-deterministic? Once a thread has been chosen to handle your
request (assuming you are using a standard HTTP connector and not
Comet or WebSocket), then that thread will be used to execute all the
code required to complete that request. Other threads may be running
simultaneously, but that should not interfere with the profiling as
the profiler's job is to determine how much CPU time is being used,
not how much wall-clock time is being used.
> Is there any chance that I get different profiles for exactly two
> same runs ?
If you are looking at wall-clock-time, then of course: your code may
stall for any number of reasons including being interrupted by another
thread or process, a hypervisor process if you are on a virtual
machine, the OS experiencing a page fault, reading from the disk,
waiting for entropy from the entropy source, etc. The JVM can get in
the way, too: you can stall waiting for the JIT to recompile your
code, garbage-collection, etc.
If you are looking at CPU cycles taken by your code, your results
should be more stable.
> (I don’t have any option to include the class which needs to be
> profiled in my profiler. So if I want to test the above I have to
> specify all other classes except org/apache/jsp in my exclusion
> list which is very time consuming. If I am sure that methods of
> apache/jsp/* classes are not time dependent, I can do that.
So you cannot include specific classes, but you can exclude specific
classes? I'm surprised that you can't use some kind of pattern to
cover lots of classes all at once. If you can exclude but not include,
you may be able to do something like this:
profiler.exclude.packages=org\.apache\.catalina\..*,
org\.apache\.coyote\..*,
org\.apache\.el\..*,
org\.apache\.jasper\..*,
org\.apache\.tomcat\..*
If you only want to profile your own code, then you probably want to
exclude java.*, javax.*, etc. but then you are kind of cheating ;)
Honestly, if you want to properly profile your code, you need to do this:
1. Move the code to be profiled into a separate class, methods, etc.
2. Re-write your JSP to use this support class.
3. Profile your support class.
Your JSP shouldn't have anything in it besides presentation logic
(e.g. looping over collections to print stuff to the page), so there
shouldn't be a lot of profiling you need to do of a JSP page.
If you are worried about the performance of your JSPs, then you have
probably poorly designed your web application.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBXTr8ACgkQ9CaO5/Lv0PBPUACgs9oYOTrxP4DmLH4o73bMjv07
B4YAoKhb5nEYY3olbGBdFdeaAbNzEdS9
=n1wF
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
