On Sat, Aug 1, 2020 at 12:53 PM Aryeh Friedman <aryeh.fried...@gmail.com> wrote: > > What are the best practices for (open source) profiling a JSP (no taglibs
There's no "one rule" for this > or any EE outside of JSP and JDBC) webapp running on a remote machine all > the way down the method level (our main user is complaining about > performance and we have done all the easy fixes that can be done without > profiling). I have played with VisualVM and while it was helpful in > finding the grosser high level stuff it was not the best for pinpointing > specific bottlenecks in the actual code. You can't rely on **one single** profiler - we use multiple profilers, because they each have their strengths and weaknesses. We write software that is both in our Hosted environment and installable in the client environment. We support WebLogic, WebSphere, and Tomcat. There are occasions where we need to profile / debug in our Hosted environment ... or mimicking a client's environment[1]. Basically, we follow the same pattern: a) Mission Control and VisualVM and Yourkit - for broad strokes b) Stackify Prefix (or other Java Agent profiler like XRebel, or maybe an Aspect type) c) AppDynamics - APM type We profile / debug in the steps outlined above - we use (a) to see if we can nail down the issue - if not, we move to (b) and (c). Don't take this list of products as gospel - there are others, and maybe you already have a license for a comparable toolset. The key is, "don't rely on just one toolset". [1] We prefer to not profile / debug in a client's environment, because there may be "too much going on elsewhere". We create a VM and use their OS, then install our software per our specs, using the AppServer they have chosen. If we see better performance in our client-replicated environment (our VM), than in theirs, we suggest to them to get with their DevOps team to find the "other source" that is contributing to their performance issue - that may involve the vendor of said redirector/etc. ** One thing to keep in mind - when you are testing, test directly to the AppServer (for example, browser <-> AppServer) and do NOT use a redirector [in front of the AppServer] that the client might be using. We have discovered 80% of client performance issues ended up being with their redirector). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
