On Wednesday, 12 November 2014 01:11:54 UTC+1, Ben Noordhuis wrote:
On Tue, Nov 11, 2014 at 12:04 PM, Andreas Marschke
thanks for your pointers.
The fact that I need an API-key and have to (If I understand you
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
Maybe I didn't explain it well but in metrics-only mode, no data is
sent to our collector. Basically, the agent collects metrics
in-process and your agent.use() callback is the data sink. We have
more advanced options for clustered applications but that's the basic
mode of operation.
Ah my bad. But thanks for the information I will check it out. Thanks.
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.
There was a "birds of a feather" session in Vancouver in August; my
co-worker Sam represented StrongLoop.
To the best of my knowledge, not much came of it and I suspect that's
because there is not much overlap in the wants and needs of the
stakeholders. About the only thing everyone could agree on is that it
would be great if we don't have to monkey-patch everything when
instrumenting applications and that is what Trevor Norris's
async-listener work is trying to do.
The fact that you came to no consensus during the discussion makes me
wonder how the BoF worked and/or how you went about finding consensus.
Sure existing tools that could be improved are always there. But the
question is can you with an acceptable amount of effort improve them to
whole or most parts of the node-community.
The much more (to me at least) frustrating thing about this is that node
as a scripting language is not the first to experience these painpoints and
will not be the last. And I cannot imagine that 99% of the able-minded
community around NodeJS came from wrinting Jquery to writing Node all day.
(Not to undermine or devalue those who HAVE come from a pure
Most of us have (IME) either a CS-Degree or some form of former knowledge
towards these things and have seen other projects/languages struggle
under similar conditions in other areas.
came from a Frontend World where performance is king especially when
improving on a
byte-level what has been (sometimes) ruined on the BL-level, it bogels my
mind that there are not much else except the Webtoolkit from Blink/Webkit
what was wrong.
The question is too how much of what is to be analysed and understood is
actually Node and not v8 and how have v8-developers been standing towards
The situation is different from node-forward. With that project, it's
clear what the problems are that need to be addressed, and there is
broad consensus on how to make it happen.
I'll have a look at node-forward. Granted it is not necessarily performance
focused but being a sort of self-help/support-group makes it kind of
worthwhile to be checked out,