绝不是，NewRelic通过许多成功的部署来掀起风暴。但是在生产中使用它的缺点是什么？
PHP监视代理程序用作.so扩展名。如果我理解正确，它会连接到另一个系统聚合服务，该服务会过滤数据并将其推送到NewRelic云中。
这仅仅意味着它在引擎盖下透明地工作。但是，这是真的吗？任何监视，分析或api服务都会给整个堆栈增加一些开销。扩展本身是0.6 MB，这加起来每个PHP进程，这不是很多，所以我关心的是CPU和IO。
该图显示了使用NewRelic代理（顶部蓝色）和没有代理（其他行）的生产EC2 t1.micro实例上的CPU利用率
您的里程可能会因设置，特定网站的代码库等而异。
您看到的额外开销是使用的内存较少，但是您的PHP代码的跟踪和分析以及收集分析数据以及数据库请求分析。基本上一些额外的开销挂钩到每个PHP函数调用。如果你让Xdebug或ZendDebugger在机器上运行或分析，你会看到类似的开销。任何模块都会使用一些资源，那些深入剖析的资源可能是最昂贵的，但我看到新的遗物有配置设置来回拨它的配置文件的密集程度，所以你可能能够比Xdebug更能减轻它的影响力。
所有这一切，新的共享PHP模块加载了他们网站的默认设置和配置我公司的网站整体服务器响应延迟当我们为我们所有的生产机器打开时，全面上升了大约15-20％。我只是谈论php-fpm生成初始响应所需的时间。我们的网站是http://www.nara.me。 newrelic-daemon和newrelic-sysmon服务也在运行，但我怀疑它们对响应时间有任何影响。
不要误会我的意思，我喜欢新的遗物，但在我的特定情况下击中的性能并没有让我想让PHP模块在所有我们的实时负载平衡机器上运行。我们可能会一直在一台机器上运行它。我们计划将sysmon的内容保持100％并保持模块禁用，以防我们需要它进行故障排除。
我的建议如下：
if(function_exists ( $function_name ))块中包含对新relic函数的任何调用，这样如果未加载新的relic模块，代码可以无错误地运行还有一件事需要记住，如果您的主要信息来源是新的遗物网站：他们通过您正在监控的机器数量获得报酬，所以不要指望他们说服您不要在任何低于100％的机器上使用它你的机器，即使它不需要。我认为其中一个常见问题解答或博客基本上表明您应该期待一些性能影响，但如果您按预期使用它并修复您从中看到的问题，您应该收回丢失的延迟。我同意，但我认为一旦你解决了这些问题，就要将暴露限制在所需数量最少的服务器上。
代理不应该像设计那样增加很多开销。由于充分解决问题所需的详细程度，这似乎是一个很好的问题，在https://support.newrelic.com问