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. > 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 > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
