Is there the SET of tools that you can work while being offline ? so you don't need to communicate to other server, login to other system... Just like node-inspector, but for profiling and monitoring ?
On Saturday, November 15, 2014 7:05:33 AM UTC+4, Andreas Marschke wrote: > > Hi Alex, > > thank you very much. Has any of the work that you and your company have > made filtered back to the community in any way? Just interested. > Because as we've already realized in this Thread. The tools in the > community is very barebones or not entirely interoperable or anything. > > At best -- to my mind -- there should a better (maybe even standardized?) > toolset or set of libraries to better understand the layers and what is > going on in the application. > Sure Node being Node means some optimizations are already there (v8 coming > from Chrom(e/ium)) but you still have javascript as your "FootGun" (see > Crockford). > > Like I suggested there could/should be a concerted effort towards that. > > Thanks! > > <!-- please stop me if I've become rambly about this... --> > > On Friday, 14 November 2014 23:48:28 UTC+1, Alex Gounares wrote: >> >> Hi Andreas >> >> Another option to consider for performance monitoring is Concurix ( >> http://concurix.com >> <http://www.google.com/url?q=http%3A%2F%2Fconcurix.com&sa=D&sntz=1&usg=AFQjCNGPxiJSn_vx9yQseOZiyKqy3u0InA>). >> >> 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/93017219-01e7-40ec-9738-0cfe6ff8dc75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
