On Sat, Aug 1, 2020, 15:16 Aryeh Friedman <aryeh.fried...@gmail.com> wrote:
> On Sat, Aug 1, 2020 at 3:28 PM calder <calder....@gmail.com> wrote: > > > 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. > > > > > > [1] We prefer to not profile / debug in a client's environment, > > because there may be "too much going on elsewhere". > > > > Ours is a custom web app (remote cardiac monitoring/record keeping) that > has only one production server and thus might make the choices narrower. > The primary problem is it runs just fine on our development machines (even > under stress tests) because we have more efficent setup then what their > hosting company is willing to provide (we already use VM's and have them > backed by local SSD's w/ traditional file systems but the hosting company > insists on doing networked object storage [which is impossible to model > outside of that environment]). When not loaded outside of peak business > hours it also runs just fine on the hosting company. Thus it comes down > to a problem only when it is under a production load and the client is not > willing to pay for a duplicate setup at the hosting firm (nor would it let > us see it under load). Our main goal in profiling is to identify which > classes/methods that are the bottlenecks. We are fairly sure it is > backend I/O driven and just need to see which of the I/O calls are the big > offenders so we can work out ways of avoiding making them. > > As to debugging except for confirming the bug in production and/or using > its logs to pinpoint the bug we do not do debugging in production. > You'll probably want to look at an APM type, such as AppDynamics
