Hi Andreas Another option to consider for performance monitoring is Concurix (http://concurix.com). Full disclosure--I am the founder and CEO there!
We have a fully on premise profiling and monitoring solution for Node.js. There is no API key or signup needed, and it runs on stock Node.js on any OS. Concurix works by injecting performance instrumentation at load time at a source level versus using the v8 profiler. This has the advantage of providing monitoring/profiling across the entire app, not just a limited set of libraries. It also means you can continuously run the profiler, even in production. However, it does mean the profiling is at a higher semantic level (the function/module level) versus say the v8 profiler. Give it a whirl and we'll be happy to help you out! regards, alex [email protected] On Tuesday, November 11, 2014 3:04:36 AM UTC-8, Andreas Marschke wrote: > > Hi Ben, > > thanks for your pointers. > > The fact that I need an API-key and have to (If I understand you > correctly) still send my data to the service provider (in worst case > even through the same network interface as my data I need to process comes > in from) means I still have no control over my data > and sorry but some more security conscious potential customers may take an > issue with that. Besides the fact that I'll have to > doubly saturate my existing bandwidth to get it somehwere else is slightly > questionable. What I actually meant by "master of > my own data" (granted the terminology is a bit messy here) is 1) I keep my > data on my premises and get to validate and evaluate > it myself. A solution (and still use StrongLoop) would be providing an > appliance or installation package for "on-premise" deployment > for StrongLoop. > > Since you said that the landscape is "scattered" regarding performance and > profiling and the like. Would it be an improvement to > commence something like a roundtable of the elders to start "Working > Group" or (in theory more agile than a committee) that would > define, support and create standards as to what to profile? Maybe even ask > people from the Companies in the community (ie. > yourself and breatheren) with blink/v8/node developers together and think > of a proper way to guide community as a whole towards > a common goal of a good standard and development of good tools. I've seen > it work for years in the networking community (see > RIPE working groups) sure there will be the occasional vitriol and > unnecessary bikeshedding but if it helps more than a handful of > developers to better understand the node environment from a performance > point of view. This could be a sister project to what has > been instantiated next to the recently unveiled nodejs group. > > Just throwing it out there may it'll stick. > > Either way, thanks for the input I will review the sources. > > Cheers, > > Andreas Marschke. > > On Tuesday, 11 November 2014 01:13:28 UTC+1, Ben Noordhuis wrote: >> >> On Mon, Nov 10, 2014 at 9:03 PM, Andreas Marschke >> <[email protected]> wrote: >> > Hi, >> > >> > first off: Don't get me wrong I like the fact, that there are companys >> out >> > ther supporting nodejs with >> > extra services and "consulting". I would however prefer to be the >> master >> > over my data and learn from it >> > myself without a frontend that takes away most of the insights they >> > (probably) learned the hard way. >> > >> > So, my question is this: What do you currently prefer to monitor your >> > applications and profile their performance? >> > >> > As far as I've seen there is only a limited amount of still viable >> > solutions. I'm about to checkout tracegl. But I feel >> > that it would be lacking any helpfull understanding as seeing that the >> > project itself - in full Mozilla Fashion (see >> > i18n-abide for another example) - is barely documented and seems to >> support >> > a limited amount of platforms >> > currently(Mostly those that support WebGL and have it enabled, which is >> not >> > the case for me most of the time). >> > >> > Other Solutions (ie. node-profiler ) have been gutted to an extend as >> their >> > upstream dependency (v8) has >> > removed most of the functionality they so heavily depend on. >> > >> > Another pain point as I see it in profiling my nodecode is, that I >> don't run >> > on illu(o)mos which also makes >> > 30% - 40% of the documentation in the Joyent ("patron" of nodejs) best >> > practices for debugging/optimizing >> > profiling worthless to me. >> > >> > Is there something I'm missing at this point? I would LOVE to >> understand >> > where my code may go wrong or >> > where it is excessively brittle performance-wise, but at this stage it >> is >> > very hard for me to see much in the >> > way of a proper toolchain here. >> > >> > Have there been any noteworthy projects around Node performance that I >> have >> > simply been missing? >> > Is it worth reading the Node C/C++ code to get a full grasp of how it >> works? >> > Is it simply an issue of p >> > promotion in the sense that not all parts of the community have >> embraced it? >> > >> > I am happy for any and every suggestions you may write underneath this. >> Feel >> > free also to lambast me on my >> > maybe ignorant views towards services like nodetime and StrongLoop. >> > >> > Thanks in advance, >> > >> > Andreas Marschke, >> >> Full disclosure: I'm the author of node-profiler and node-heapdump and >> a StrongLoop founder. >> >> Thorsten Lorenz maintains a curated list of profiling and debugging >> tools, see [0]. Be warned that the free software landscape is still >> pretty scattered and that won't change anytime soon. Writing good, >> integrated performance/debugging tools takes time and is not very >> rewarding in itself; most of the existing tools scratch a particular >> itch and stop there. >> >> > >> If I can circle back to a comment you made at the start of your post - >> being the master of your own data; the StrongLoop agent is moving to a >> model where it simply collects the raw or aggregated metrics and >> leaves it up to you to process or store it. We provide integration >> for popular services like statsd[1], Splunk[2], Datadog[3], etc. Here >> is an example of our statsd integration[4]: >> >> var agent = require('strong-agent'); >> var statsd = require('strong-agent-statsd')(); >> agent.use(statsd); // that's all, metrics are now reported to statsd >> >> You can find more details in the README[5]; scroll down to the section >> on the metrics API. Questions or suggestions welcome. >> >> [0] https://github.com/thlorenz/v8-perf >> >> [1] https://github.com/etsy/statsd >> >> [2] http://www.splunk.com/ >> >> [3] https://www.datadoghq.com/ >> >> [4] https://github.com/strongloop/strong-agent-statsd >> >> [5] https://github.com/strongloop/strong-agent/blob/master/README.md >> > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/ed74412d-d65c-4937-9afb-c3e60da51bce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
