我们有一个REST API。对于此API提供的每个端点，我们都基于内部测试定义了SLA。 New Relic提供了一个选项，可以根据每个应用程序定义Apdex T分数。考虑以下情况：
平均SLA：500ms
情况1：考虑Apdex阈值的平均SLA 这种方法的问题在于，即使我的端点A预计在200毫秒内完成，即使端点花费了SLA中定义的时间的两倍，也不会对其进行标记，因为它仍然小于平均值。反之亦然，对于端点B，即使它在800ms以下，也会对其进行标记。
情况2：将所有端点的最大SLA（800ms）视为Apdex T值 再次出现问题，这是端点A。即使花费4倍于实际预期时间，也不会标记来自此端点的任何响应延迟。
那么，在这种情况下，我们如何得出Apdex阈值？ 我浏览了以下来自新文物的文章：LINK。当我们将服务视为一个整体时，这是有意义的，但是当我们查看每个端点时，这是没有意义的。
答案 0 :(得分：1)
确定要根据您的SLA设置Apdex吗？
我建议应用程序的典型性能是更好的指标。假设过去7天内您的应用程序性能平均。但是，在“如何设置Apdex T”中，本文建议使用百分位数来实现典型性能。
因此，如果您获得第90个百分位数，则通常应得出接近0.95的Apdex得分。显然，Apdex为1是没有用的，因为您没有将帐户保持在足够近的帐户附近。所以我会单独问见解
从7天前从其中appName =“ AppA”的交易中选择百分位数（duration，90）
从7天前的appName =“ AppB”中选择交易的百分位数（duration，90）
这将使您90％的客户变得比以前更好。因此，对于您的Apdex T值，应该是一个很好的大致指导。
但是，如果您的目标是在SLA为200ms的App A上进行任何交易，则其对Apdex得分应为0分。那么很简单，您的Apdex T应该是50ms。因为任何比50ms快的东西都会得到1分，所以Apdex T和4 x Apdex T之间的任何东西都会得到0.5分，但至少仍然得分。任何慢于4 x Apdex T（在这种情况下为200毫秒）的东西都将获得指向Apdex的0分。因此，如果它们违反了SLA，则将为您标记为Apdex沮丧的事务。
Apdex有点艺术，但是您绝对可以通过上述两种方法到达需要的地方。我希望我能掩盖我认为在这种情况下可能出现的两种情况。