Hello Tim! Firstly, thank you for this wonderful profiler. I thought it was sexy BEFORE it got flame graphs.
The way I usually use NYTProf is I try to think which part of my web app might be slow, or get run a lot, and profile it on my test machine. This has been terrifically useful and revealed some great potential optimizations. However, I have a vision for taking this to the next level and implementing it in the production environment, like this: 1. When Apache starts, it loads Devel::NYTProf::Apache as per the docs, but with "start=no" 2. Every few thousand requests, the web app calls DB::enable_profile($unique_filename) at the start of the request and then DB::finish_profile() at the end, to grab a sample of live traffic. 3. Once a day, the server runs nytprofmerge and nytprofhtml to generate beautiful HTML. This actually works and is incredibly useful because it answers two questions at once: "Which areas of the code are our users hitting most?" and "Which areas of the code are slower than they should be?" That is infinitely better than me guessing at the first question and profiling what I think looks suspicious, since I am never going to get the answer right. (In particular, it's hard to predict what combinations of user account settings and pageviews might cause unnecessarily high load.) Unfortunately, it only works under Apache MPM prefork. And prefork isn't a practical option in production, because our web app receives hundreds of concurrent connections, which prefork would require enormous amounts of RAM to satisfy. I understand from the docs that NYTProf is not thread-safe. So when I try the above on a machine running Apache MPM worker, NYTProf simply does a lot of this: ~ init_profiler for pid 27194, clock 1, tps 10000000, start 0, perldb 0xf10, exitf 0x2 ~ init_profiler done ~ enable_profile call from different interpreter ignored ~ finish_profile call from different interpreter ignored ~ enable_profile call from different interpreter ignored ~ finish_profile call from different interpreter ignored I'm writing in anyway because I'm holding onto the hope that this need not apply in my limited case, where I only want to start profiling after Apache has created a thread and finish profiling in that same thread. I don't need NYTProf to follow an Apache process through a fork or whatever it does. In fact, if it matters, I'd be happy to limit the profiling to a single grab from each MPM worker process--they get recycled reasonably often, so that would still provide enough profiling data to be useful. I just want to be able to sample live data. What do you think? Thank you again for your marvellous software, Max. -- -- You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected] --- You received this message because you are subscribed to the Google Groups "Devel::NYTProf Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
